Best Practices for Next-Gen Firewall as a Service (NGFWaaS)

Multi-Factor Authentication 

For NGFWaaS, enforce multi-factor authentication (MFA) through the upstream IdP, such as Microsoft Entra ID or Okta, or directory service for captive portal and passive authentication flow. Ensure that your IdP's conditional access or MFA policies apply to all authentication flows that feed into the NGFWaaS captive portal. For passive authentication users, enforce MFA at the endpoint or directory login so that identity is verified before VMS maps the user-to-IP session. For Concerto administrator logins, enable IdP-provided MFA to protect the management plane.

Session Control and Revocation

• For captive portal users, configure idle and absolute session timeouts to limit the window of exposure from unattended sessions.
• Define and enforce SLAs for access revocation on the IdP to ensure prompt responses to role changes and employee departures. Configure immediate access revocation upon identity disablement or employee termination without manual intervention.

Tunnel Design Considerations 

• Deploy redundant tunnels for high availability (HA)—Establish redundant IPsec tunnels to separate SSE gateways within the same region. Each tunnel must use a unique peer ID and distinct pre-shared keys (PSKs). If the primary tunnel fails, traffic fails over to the secondary without interrupting security enforcement or user connectivity. 
• Configure SSE gateway in Responder-only mode—Ensure that tunnel initiation is controlled by trusted peer devices. Traffic or Automatic modes should be used only when the peer device cannot initiate the tunnel. 

Recommended Cryptographic Parameters 

• Use strong cryptographic parameters—Select parameters that meet or exceed current industry standards:
  • AES-256 encryption
  • SHA-384 or SHA-512 hashing
  • Diffie-Hellman Group 16 for key exchange
• Rotate PSKs on a defined schedule—Rotate keys at least annually and immediately upon personnel changes or suspected compromise.

General Tunnel Security Practices 

• Prefer certificate-based authentication—Where supported, use certificate-based IPsec authentication instead of PSKs. Certificate-based authentication reduces exposure associated with shared-key handling, mis-configuration, and credential leaks, and scales more cleanly in multi-site deployments.
• Isolate the management plane—Restrict management plane access to site-to-site tunnel endpoints to dedicated management networks only. Administrative interfaces must not be reachable from the data plane or the public internet.
• Log all tunnel state changes—Forward tunnel establishment, teardown, and rekeying failure events to a centralized SIEM. Correlate tunnel events with access logs for faster detection of connectivity anomalies and potential tunnel-based attacks.

Rule Match Criteria 

• Defined named applications and not CIDR ranges—Define internet services and applications as named application objects or application groups in Concerto instead of granting broad CIDR-based or wildcard reachability. Named applications make policies readable, auditable, and easier to tighten as the environment evolves.
• Leverage URL categories for broad internet governance—Use URL category filtering to control access to classes of internet content (e.g., social media, gambling, malware, streaming) without defining individual applications. Combine URL categories with user or user group context to enforce differentiated policies, for example, blocking high-risk categories for general users while permitting them for specific teams with business justification.
• Use application ID and shadow IT sanctioning—Use application ID classification to identify applications by their actual behavior, instead of relying solely on port or protocol. Use the sanctioned/unsanctioned tagging in Concerto to distinguish IT-approved applications from shadow IT. Build internet protection rules that automatically block or restrict unsanctioned applications while permitting sanctioned ones, reducing policy sprawl and surfacing unapproved SaaS adoption before it becomes a data leakage vector.
• Leverage shadow IT risk score as a match criterion—Use the built-in shadow IT risk scores in Concerto to create dynamic, risk-aware internet protection rules. For example, automatically apply stricter inspection profiles or block access for applications rated high-risk, while allowing lighter-touch policies for low-risk, business-critical SaaS. Risk score matching reduces manual rule maintenance by adapting policy enforcement as application risk classifications are updated.
• Scope rules to users or user groups—Configure internet protection rules at a user or user-group level, granting access only to the specific internet applications and URL categories that a given role requires. Avoid generic rules that provide uniform access to all users, which violates zero-trust principles and increases the risk of lateral movement.

Zero-Trust Policy Design and Ordering 

Internet protection rules should follow a default-deny, allow list model: all traffic should remain unauthorized unless explicitly permitted by an allow rule, and every allow rule must carry a documented business justification. Rules evaluate top-down, first-match, so rule ordering directly determines enforcement outcomes. Establish a behavioral baseline before building the production rule base, either by deploying temporary allow rules with full logging, or by using existing firewall rules as a starting point. Structure the rule base in the following six tiers, evaluated in order: 

• Exception rules (highest priority)—Place narrow, time-bound exception rules at the very top of the rule base for specific users or groups that require temporary overrides, for example, an administrator who needs short-term access to a blocked diagnostic tool, or a vendor requiring temporary access during an integration window. Keep exception rules minimal and review them on a defined cadence. Every exception should carry an expiry date and a documented business justification.
• Global deny list—Immediately below exceptions, place explicit deny rules that block all known-bad traffic regardless of user or user group context, such as known-malicious URL categories, threat-feed-sourced IP addresses and domains, botnet C2 infrastructure, customer-maintained block lists, and non-sanctioned generative AI applications. Include DNS infrastructure security rules that restrict outbound DNS to trusted servers with active inspection.
• User-specific allow list—Create explicit allow rules for individual users who require access that falls outside their group's default policy, for example, a security analyst who needs access to threat-intelligence feeds that are blocked for the broader IT group. These rules override the group-level and general defaults below. Scope tightly to the specific application or URL category, attach appropriate security profiles (IPS, malware protection), and document the justification.
• Group-specific allow list—Define allow rules at the role or department level, matching on user groups defined in Concerto. Grant each group access only to the specific named applications, URL categories, and sanctioned SaaS platforms required for their function (identified through application ID and sanctioned/unsanctioned tagging). Apply tiered security profiles:
  • Lightweight—For verified low-risk sanctioned traffic (URL filtering, IP reputation)
  • Standard—For moderate-risk business-critical destinations (IPS, malware protection, TLS decryption)
• General allow rules—Permit remaining business-justified internet traffic that is not covered by the user- or group-specific tiers above. Apply the full security stack to these flows: URL filtering, IP filtering, IPS, malware protection, DLP, and advanced threat protection (ATP). Explicitly block uncategorized URLs at this tier. Traffic that cannot be classified should not be permitted through a general rule. Log all actions for baseline comparison and audit. 
• Default deny—Terminate the rule base with an explicit deny-all rule with logging enabled. Although NGFWaaS enforces an implicit deny for unmatched traffic, an explicit default-deny rule ensures that all blocked traffic is logged and visible in the SIEM. Any traffic reaching this rule should be reviewed as a potential gap in the allow list or an unauthorized access attempt and should trigger immediate investigation.

Policy Hygiene 

• Conduct regular policy-drift reviews—Perform regular policy drift reviews by comparing the active policy set against the approved baseline. Assign a clear ownership to each policy domain.
• Remove unused rules promptly—Remove unused or obsolete rules to prevent policy sprawl. Stale entries reduce visibility and increase the likelihood of unintended access.
• Eliminate any match fields from allow rules—Avoid overly permissive conditions such as setting user or match criteria to “any”. Such configurations can unintentionally grant broad access and undermine Zero Trust principles.

Security Profiles 

• URL filtering—Apply to all internet-bound HTTP/HTTPS traffic. URL filtering classifies destination URLs into categories (e.g., social media, gambling, malware, streaming) and enforces allow, block, or alert actions per category. Use URL filtering as the first line of policy enforcement for web traffic. It stops users from reaching prohibited or high-risk content before any deeper inspection is triggered. Combine URL filtering with user or group context to enforce differentiated policies by role.
• IP filtering—Apply to all traffic, both web and non-web. IP filtering evaluates source and destination IP addresses against reputation databases and threat-feed-sourced block lists. Use IP filtering to block traffic to and from known-malicious infrastructure (botnet C2, tor exit nodes, anonymous proxies) regardless of application or protocol. IP filtering operates at the network layer and adds minimal latency, making it suitable as a baseline profile on every internet protection rule.
• DNS filtering—Apply to all DNS resolution traffic. DNS filtering inspects DNS queries and blocks resolution of domains associated with malware, phishing, C2 infrastructure, and policy-prohibited categories. Use DNS filtering as a pre-connection control to prevent sessions from being established to malicious destinations before any TCP handshake occurs. This reduces the attack surface at the earliest possible stage. DNS filtering is particularly effective against threats that rely on domain generation algorithms or fast-flux DNS.
• Intrusion prevention system (IPS)—Apply to all permitted traffic where exploit detection is required. IPS inspects packet payloads against signature databases to detect and block known vulnerability exploits, buffer overflows, and protocol anomalies in real time. Deploy IPS in inline blocking mode on all internet protection rules that permit traffic to business-critical or high-risk destinations. IPS is most effective when paired with TLS decryption so that encrypted payloads are visible for inspection.
• Malware protection—Apply to all traffic where file transfer is technically possible. Malware protection, also referred to as antivirus, performs real-time scanning of files transferred over HTTP, FTP, SMTP, POP3, and IMAP using signature matching, heuristics, and emulation. Use malware protection on every rule that permits web browsing, email, or file-sharing access. Do not limit malware protection to web traffic alone because malware delivery through email attachments and FTP transfers remains a primary attack vector. Malware protection requires TLS decryption to inspect files within encrypted sessions.
• Generative AI governance—Versa Networks identifies generative AI applications through two mechanisms: URL category matching using the built-in Generative AI URL category, and App-ID classification or application groups that target specific AI tools. Use these to build explicit per-population policies: block for roles handling regulated or sensitive data, allow with DLP inspection for approved users who have a business need, or allow with logging and monitoring for general users. AI applications present distinct data leakage risks because users may submit proprietary information as prompts, making deliberate, role-based policy essential rather than a blanket allow or block.

Recommended Profile Stacking 

No single profile type covers the full threat landscape. It is recommended that you stack profiles so that each traffic category receives inspection in proportion to its risk, balancing depth against gateway performance. 

• Web-bound traffic (HTTP/HTTPS)—Apply the full stack (URL filtering, IP filtering, DNS filtering, IPS, and malware protection). Enable TLS decryption for these flows so that IPS and malware protection can inspect encrypted payloads. This is the highest-risk traffic category and warrants maximum inspection depth.
• Non-web traffic (non-HTTP protocols)—Apply IP filtering and IPS at a minimum. Add malware protection for protocols that carry file transfers (FTP, SMTP, POP3, IMAP). URL filtering and DNS filtering are not applicable to traffic that does not use HTTP or DNS resolution.
• Low-risk sanctioned SaaS—Apply URL filtering, IP filtering, and DNS filtering as a lightweight baseline. IPS and malware protection may be applied at reduced depth for verified, low-risk applications to optimize gateway performance while maintaining visibility.
• High-risk and uncategorized traffic—Apply the full stack (URL filtering, IP filtering, DNS filtering, IPS, and malware protection) with mandatory TLS decryption. Uncategorized URLs and high-risk categories should receive the deepest inspection available. Consider adding DLP and advanced threat protection (ATP) for destinations where data exfiltration risk is elevated.

Decryption Certificate Management  

• Use a dedicated intermediate CA—For production TLS decryption, use a dedicated intermediate CA certificate rather than the default Versa Private CA certificate. Generate a dedicated intermediate CA certificate (including its private key) specifically for SSE gateway decryption. 
• Isolate the decryption CA—The intermediate CA used for TLS decryption must be issued exclusively for this purpose and must not be deployed elsewhere in the organization’s infrastructure. This limits the blast radius of a key compromise and preserves the certificate chain of trust.

Decryption Rule Design  

• Avoid decrypt-all as a default policy—TLS decryption is CPU-intensive and should be applied selectively. Prioritize decryption for high-risk, suspicious, undefined, and moderate-risk URL categories where security inspection provides the greatest value. 
• Bypass sensitive categories explicitly—Create explicit bypass rules for traffic in regulated or privacy-sensitive categories, including financial services, healthcare, government and defense, and identity providers. Place bypass rules above general decryption rules so they are evaluated first. 
• Handle certificate-pinned applications carefully—Bypass certificate-pinned applications by enabling the Bypass Certificate-Pinned Traffic option in Concerto. For certificate-pinned traffic, bypassing preserves application functionality while aligning inspection policy appropriately. 

General TLS Security Practices 

• Enforce a minimum TLS version—Most applications have moved to 1.2 and higher. If TLS 1.1 is required for legacy applications, create a narrow exception rule scoped to those specific applications only. Keep the global minimum unchanged and create narrowly scoped exceptions for legacy edge cases where required.
• Enable certificate revocation checking—Enable CRL/OCSP validation for high-risk sites to detect and block connections to servers presenting revoked certificates. Revoked certificates are a strong indicator of compromised infrastructure and should never be silently accepted.
• Log all TLS decryption events—Forward TLS decryption logs including bypass events to the SIEM. Decryption bypass logs are valuable because they provide visibility into traffic that is intentionally excluded from decryption and may warrant periodic policy review.
• Regularly review TLS decryption bypass rules—Conduct a periodic review of bypass rules. Exemptions granted during initial deployment (for example, for application compatibility) may no longer be necessary as applications update their TLS implementations. Stale bypass rules erode the value of the decryption investment and should be treated as technical debt with a clear review cadence.

Access Reviews and Audit Logging

• Conduct periodic access re-certification using the Analytics and Reporting capabilities in Concerto. Review "Top Applications" and "User Access" reports to verify that policy enforcement aligns with current business requirements. Perform weekly review of denied-traffic trends and access anomalies: deny logs reveal both legitimate access gaps and potential reconnaissance activity. Repeated denial patterns from the same user or device may indicate mis-configuration, credential compromise, or an active probing attempt.
• Review shadow IT discovery reports in Concerto to identify newly adopted, unsanctioned applications. Cross-reference discovered applications against the sanctioned/unsanctioned tagging and update internet protection rules to block or restrict any unapproved SaaS to maintain visibility and policy alignment across data paths.
• Audit rules for expiry and continued relevance—Review rules at least monthly to confirm they still have a valid business justification and have not exceeded their intended duration. Remove or tighten rules that are no longer needed. Compare granted access against actual usage in Analytics and remove permissions that are no longer exercised. Access rights tend to accumulate over time, and periodic tuning counteracts this drift.
• Validate TLS decryption bypass coverage—Review the TLS bypass rule list in Concerto to confirm that each exemption still aligns with current compliance and privacy requirements. Exemptions granted during initial deployment may no longer be necessary as applications update their TLS implementations.
• Post-incident policy reassessment—Reassess all NGFWaaS policies immediately after any security incident. An incident may reveal policy gaps, overly permissive rules, or enforcement failures that were not visible during routine operations.

Logging and SIEM Integration

• SASE web logging should be enabled at the tenant level. Logs are the primary evidence source for incident investigations and the only basis for access re-certification.
• Forward logs to a centralised SIEM in real time. Retain logs in accordance with your compliance obligations. Most regulatory frameworks require a minimum of 12 months online retention with multi-year archival.
• Define alerts based on deviations from baseline, not only on known-bad signatures: spikes in denied connections, unusual geo-locations, anomalous data-transfer volumes, or repeated authentication failures. Establish a traffic baseline in the first weeks of deployment and build threshold alerts against it.
• Alert on posture violations and policy exceptions in real time: sudden changes in traffic mix, new application categories appearing in logs, or a significant increase in TLS bypass matches.