- Join Our Company
- Email: sanjay@pjnetworks.com
- Phone: +91-9818361787
Every year, security analysts publish a consistent finding: the majority of serious network breaches are not the result of zero-day exploits or nation-state toolkits. They stem from configuration errors — firewalls with overly permissive rules, stale administrator accounts, disabled logging, or default credentials that were never rotated. For Indian enterprises running FortiGate appliances, this is not a theoretical risk. It is a daily operational reality that managed security providers encounter in audit after audit.
This post breaks down the most common FortiGate misconfiguration patterns we see across mid-to-large Indian enterprise estates, explains why they persist, and outlines a practical hardening and monitoring programme that eliminates the silent gaps before an attacker finds them first.
FortiGate is one of the most widely deployed next-generation firewall platforms in India. It is capable, policy-rich, and deeply integrated with the broader Fortinet Security Fabric. But capability is not the same as correct configuration. Several structural pressures conspire to leave FortiGate deployments in a degraded security state over time:
Each of these conditions, in isolation, represents a moderate risk. In combination, they create the conditions for a serious breach that appears, in hindsight, entirely preventable.
Based on configuration review engagements conducted across Indian manufacturing, BFSI, and IT/ITES organisations, these are the misconfigurations that create the highest-impact exposure:
A “permit any any” rule — or its functional equivalent, a broad rule with source “all” and destination “all” — that also has logging turned off is effectively invisible to the security team. Attackers can traverse the network laterally for weeks without triggering a single alert. FortiGate’s traffic logging should be enabled at minimum for all rules with broad source or destination objects.
FortiGate ships with an “admin” account and no default password (the installer sets one at first boot). However, environments migrated from older platforms, or recovered from backup, occasionally revert to weak or predictable administrative credentials. Credential stuffing attacks that target HTTPS management interfaces are a real and growing threat.
Exposing HTTPS or SSH management on a WAN-facing interface — even with a trusted-host ACL — dramatically increases the attack surface. FortiOS has seen a number of CVEs in its SSL-VPN and HTTPS management stack. Running management on a dedicated, RFC-1918 interface and enforcing VPN access for remote administration eliminates this exposure.
SSL/TLS inspection is one of FortiGate’s most powerful threat detection capabilities. But exemption lists grow without governance. When banking, SaaS, and “trusted” CDN domains are broadly exempted, attackers simply host command-and-control infrastructure or data exfiltration channels on those platforms — and the firewall waves them through.
Remote access VPN user accounts — whether SSL-VPN or IPsec dial-up — frequently outlive employment. Former employees, contractors, and vendors whose network access was never revoked represent a persistent credential theft risk. A quarterly reconciliation against HR data is the minimum control; automated deprovisioning via LDAP/AD integration is the correct target state.
FortiOS receives frequent security updates. Running a FortiGate on firmware that is more than two minor releases behind means running with known, publicly documented vulnerabilities. Many Indian organisations run firmware versions that are 12–24 months old, often because “if it’s working, don’t touch it” is the prevailing philosophy. This is untenable in 2026’s threat environment.
Teams deploy web filtering in “monitor” mode to assess impact before switching to “block” mode. The transition to block mode is then deferred indefinitely. The organisation pays the licensing cost but derives none of the protection.
FortiAnalyzer is an excellent native log management platform. But logs retained only in FortiAnalyzer — with no forwarding to a centralised SIEM — create an operational island. Cross-platform correlation (firewall events against endpoint alerts, authentication logs, and cloud access logs) is what enables detection of multi-stage attacks. In the context of CERT-In’s direction on 180-day in-country log retention, logs locked in a single appliance with limited retention depth are also a compliance risk.
Without a documented baseline — what the configuration should look like — it is impossible to detect drift. A change made six months ago that weakened a policy goes unnoticed until the next annual penetration test. Continuous configuration monitoring, comparing live device state against an approved baseline, is the correct control.
High-availability FortiGate pairs that have never been properly failover-tested can carry subtle asymmetries: one node with a different firmware version, a session table that does not sync correctly, or a secondary unit that has been in maintenance mode so long that its configuration has drifted from the primary. These asymmetries become security gaps at the moment they matter most.
The following checklist reflects the FortiGate hardening standard that PJ Networks applies during managed deployments and security posture review engagements. It is not exhaustive — FortiOS is a deep platform — but it addresses the highest-frequency gaps.
The hardening checklist above addresses point-in-time configuration. What it cannot address is drift — the inevitable divergence between an approved baseline and the live state of a device under operational pressure. And it cannot address the threats that hardened firewalls still need to detect: sophisticated phishing campaigns, lateral movement via compromised endpoints, or insider actions that never touch the firewall at all. Closing those gaps requires a continuous SecOps capability. PrahiX Ora is the unified SecOps platform that PJ Networks deploys and operates for clients, and its four pillars are directly relevant to the FortiGate hardening problem.
SIEM — Correlated visibility across every log source. FortiGate generates rich traffic, threat, and authentication logs. But meaningful detection requires those logs in context: alongside Active Directory events, endpoint telemetry, cloud access logs, and application data. Ora’s SIEM ingests multi-source log streams, applies correlation rules mapped to MITRE ATT&CK tactics and techniques, and reconstructs multi-step attack storylines using graph-based analysis. This is particularly relevant to CERT-In’s direction that organisations retain logs in-country for 180 days — Ora’s tiered retention architecture (hot, warm, and archive tiers) supports that requirement without requiring organisations to over-provision expensive primary storage.
NMS — Unified observability for complex, multi-vendor estates. Many Indian enterprise networks are not pure FortiGate estates. A mix of legacy switches, access points from multiple vendors, and SD-WAN links creates the NOC visibility problem: no single console shows the full picture. Ora’s Network Management System uses LLDP/CDP topology discovery to map the estate automatically, provides unified observability across firewalls, switches, APs, and WAN links, and applies ML-based anomaly detection that can surface unusual traffic patterns before they appear in firewall logs. For network operations teams managing geographically distributed estates across India — a common profile among manufacturing and retail clients — this unified view significantly reduces mean-time-to-detect (MTTD) for network-layer incidents.
Video Surveillance (VMS) — Physical and network security under one operations view. For manufacturing plants, retail chains, and multi-site enterprises, physical access events and network security events rarely appear in the same operations view. Ora’s video surveillance (VMS) pillar integrates ONVIF, Hikvision, and Dahua camera management with video analytics, bringing physical and logical security data into a single platform. An access control event — a tailgated entry after hours — correlated with an unusual authentication attempt on the same floor, at the same time, becomes a meaningful alert rather than two unconnected data points.
SOAR — Automated response that makes CERT-In’s 6-hour window realistic. India’s CERT-In 2022 direction requires organisations to report certain cybersecurity incidents within six hours of detection. For a human analyst working a 300-alert queue at 2 AM, a six-hour reporting window is aspirational without automation. Ora’s SOAR layer provides pre-built playbooks and automated response actions — including pushing updated blocklists directly to FortiGate — that reduce the response timeline from hours to minutes. When an Ora SIEM correlation rule fires on a suspected credential stuffing campaign, the SOAR playbook can automatically quarantine the affected accounts, update the FortiGate blocklist, and generate a draft CERT-In incident report, all within the window that manual processes would consume just in initial triage.
If your organisation is evaluating a continuous SecOps capability to underpin a FortiGate hardening programme, PJ Networks can walk you through a live demonstration of Ora in a deployment context matched to your estate profile.
India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and CERT-In’s 2022 directions have raised the compliance stakes for enterprise network security in ways that make firewall misconfiguration a board-level risk.
Under the DPDP Act, data fiduciaries are required to implement appropriate technical and organisational measures to protect personal data. A misconfigured FortiGate that permits unauthorised lateral movement — enabling an attacker to reach a customer database — is a technical failure that directly supports a finding of inadequate protection. While the DPDP Act does not prescribe specific technical controls, regulators will scrutinise whether reasonable security practices were in place at the time of a breach. A documented hardening programme, continuous configuration monitoring, and a SIEM that captures and correlates relevant events all help evidence that reasonable measures were implemented.
CERT-In’s directions are more prescriptive: the 6-hour incident reporting window, the 180-day in-country log retention requirement, and the obligation to maintain accurate ICT asset inventories are all directly relevant to the FortiGate operational posture. Organisations that cannot produce 180 days of correlated network logs, or that cannot determine within six hours whether an incident meets reportable criteria, face regulatory exposure in addition to the underlying security risk.
Firewall misconfiguration is not just a technical risk — it is a compliance risk. The DPDP Act and CERT-In directions have made the quality of your network security controls a matter of regulatory record.
For most Indian enterprises, moving from an unreviewed FortiGate estate to a continuously monitored, hardened posture is a multi-quarter programme, not a single project. A pragmatic phasing looks like this:
If you manage or oversee a FortiGate deployment in an Indian enterprise and have not conducted a systematic configuration review in the past 12 months, the following immediate actions will materially reduce your risk exposure:
These five checks take an afternoon for a single-site deployment. For multi-site estates, they represent a prioritised starting point for a phased review programme.
PJ Networks is a managed security provider with deep FortiGate and Fortinet Security Fabric expertise, operating a 24/7 NOC/SOC from India. Our services relevant to the hardening programme described in this post include:
To schedule a FortiGate configuration review or discuss a managed security engagement, contact PJ Networks through pjnetworks.com/contact.