NSE7_SSE_AD-25 Questions and Answers

Zero Trust Network Access (ZTNA) is the FortiSASE feature that ensures least-privileged user access to all applications. ZTNA operates on the principle of " never trust, always verify, " providing secure access based on the identity of users and devices, regardless of their location.

Zero Trust Network Access (ZTNA):

ZTNA ensures that only authenticated and authorized users and devices can access applications.

It applies the principle of least privilege by granting access only to the resources required by the user, minimizing the potential for unauthorized access.

Implementation:

ZTNA continuously verifies user and device trustworthiness and enforces granular access control policies.

This approach enhances security by reducing the attack surface and limiting lateral movement within the network.

The Secure Web Gateway (SWG) policy is used to control traffic between the FortiClient endpoint and FortiSASE for secure internet access. SWG provides comprehensive web security by enforcing policies that manage and monitor user access to the internet.

Secure Web Gateway (SWG) Policy:

SWG policies are designed to protect users from web-based threats and enforce acceptable use policies.

These policies control and monitor user traffic to and from the internet, ensuring that security protocols are followed.

Traffic Control:

The SWG policy intercepts all web traffic, inspects it, and applies security rules before allowing or blocking access.

This policy type is crucial for providing secure internet access to users connecting through FortiSASE.

Onboarding a Secure Web Gateway (SWG) endpoint involves several components to ensure secure and effective integration with FortiSASE. Two key components are the FortiSASE CA certificate and the proxy auto-configuration (PAC) file.

FortiSASE CA Certificate:

The FortiSASE CA certificate is essential for establishing trust between the endpoint and the FortiSASE infrastructure.

It ensures that the endpoint can securely communicate with FortiSASE services and inspect SSL/TLS traffic.

Proxy Auto-Configuration (PAC) File:

The PAC file is used to configure the endpoint to direct web traffic through the FortiSASE proxy.

It provides instructions on how to route traffic, ensuring that all web requests are properly inspected and filtered by FortiSASE.

In the FortiSASE architecture, there are two primary methods for delivering Secure Internet Access (SIA) : Agent-based (using FortiClient) and Agentless (using Secure Web Gateway/SWG).

Use Case Analysis: The scenario describes a contractor—an unmanaged user—who requires temporary access for a web-based application (the POS system). For contractors or guests using personal/non-corporate devices where installing the FortiClient agent is either not feasible or not desired, FortiSASE provides the SIA Agentless deployment model.

Mechanism (SWG & PAC): In this mode, FortiSASE functions as an explicit web proxy . To steer the contractor ' s web traffic (HTTP/HTTPS) to the SASE cloud for inspection, the administrator provides the user with a proxy auto-configuration (PAC) file . The contractor simply configures their browser or operating system to point to the URL of this PAC file.

Security Enforcement: Once the PAC file is applied, all web traffic from the contractor ' s device is redirected to the FortiSASE SWG PoP. Here, the traffic is subject to the organization’s full security stack, including SSL deep inspection, Antivirus, Web Filtering, and Application Control , ensuring that even temporary contractor access is fully secured and logged.

Why other options are incorrect:

Option B (Tunnel Policy): This refers to agent-based access where a VPN tunnel is established. This requires FortiClient, which is generally not used for temporary contractors on unmanaged devices.

Option C (ZTNA Unmanaged): While ZTNA supports agentless access to private applications (SPA), providing internet access (SIA) to an unmanaged endpoint is specifically the role of the SWG/Proxy service.

Option D (Self-registration): While FortiSASE has a User Portal for onboarding, it is a method for user registration/credential management, not the technical traffic-steering mechanism used to provide internet connectivity.

According to the FortiSASE 25 Secure Internet Access Architecture Guide , the SWG (Agentless) approach is the recommended best practice for securing web-only traffic from unmanaged endpoints and third-party contractors.

When providing Secure Private Access (SPA) to external contractors who may not be using managed corporate devices, FortiSASE offers specific methods to ensure security while maintaining ease of use.

Bookmark Portal (Clientless Access): For web-based resources like a web server, the recommended and most efficient method for contractors is to use the ZTNA portal (bookmark portal) . This allows for clientless access , meaning the contractor does not need to install the FortiClient agent or any specific software on their personal machine.

Workflow: The administrator publishes the web server URL as a bookmark within the FortiSASE portal. Contractors simply log into the secure SASE web portal via their browser, authenticate, and click the bookmark to access the internal server.

Security Benefits: This method leverages the FortiSASE ZTNA access proxy to mediate the connection. It ensures that the contractor is authenticated and that the traffic is inspected without exposing the internal network directly to the contractor ' s device.

Analysis of Incorrect Options:

Option A: TCP forwarding rules require the FortiClient agent to be installed and managed on the endpoint. Contractors often use unmanaged devices where installing agents is restricted or undesirable.

Option C: Updating a PAC (Proxy Auto-Configuration) file is part of a Secure Web Gateway (SWG) deployment for internet access, not for routing traffic to private internal web servers via an SPA hub. 1

Option D: Manually updating DNS records on a contractor ' s endpoint is an unscalable, insecure, and administratively heavy task that does not provide the session-level security required by ZTNA.

In FortiSASE Secure Private Access (SPA) deployments, establishing a stable connection between the FortiSASE PoPs and the corporate FortiGate hub relies on two primary layers: the IPsec Tunnel and the BGP Peering .

Exhibit Analysis: The exhibit (image_577e17.jpg) shows the status of several Security PoPs (Singapore, Tokyo, Frankfurt, and San Jose) connected to an " FGT-Hub " .

Tunnel Status vs. BGP Status: For all listed PoPs, the Health Check IP Status and Tunnel status are both shown with a green " Up " icon. This confirms that the underlying IPsec connectivity and the physical path between the SASE cloud and the hub are functioning correctly.

Identifying the Failure: The BGP Peering State is reported as Active . In BGP terminology, the " Active " state specifically indicates that the router is attempting to initiate a TCP connection with its peer but has not yet received a response. A fully functional and successful BGP connection must reach the Established state.

Root Cause Determination: Since the tunnel is up (eliminating Gateway or Authentication Method issues as the primary suspects) but the BGP state remains stuck in " Active, " the most likely cause is a mismatch or misconfiguration in the BGP Peer IP or BGP neighbor settings. This prevents the exchange of routing information necessary for users to access private applications.

To resolve the connectivity problem, the administrator must ensure that the BGP neighbor IPs configured on the FortiGate hub match those assigned by the FortiSASE orchestration and that firewall policies on the hub allow BGP traffic (TCP port 179) across the tunnel.

In a standard FortiSASE agent-based deployment, the FortiSASE Endpoint Management Service (EMS) acts as the central control plane for all managed FortiClient instances. When an endpoint is onboarded, the system is designed to provide " zero-touch " configuration for the core connectivity and security components.

CA Certificate (A): For SSL deep inspection to function without triggering browser certificate warnings, the endpoint must trust the FortiSASE CA. FortiSASE supports automatically installing the FortiSASE CA certificate for managed agent-based users. Once the endpoint connects to the FortiSASE EMS, the service automatically deploys the CA certificate to the trusted certificate store of the client machine.

Tunnel Profile (B): To enable Secure Internet Access (SIA), FortiClient requires a pre-configured VPN or tunnel profile that points to the FortiSASE cloud infrastructure. In a new deployment with default settings, FortiSASE automatically pushes the tunnel profile (including gateway information and auto-connect settings) to the FortiClient endpoint. This allows the user to establish a full-tunnel connection to the nearest Security PoP immediately after onboarding.

Analysis of Incorrect Options:

Real-time protection (C): While FortiSASE can manage Malware Protection and Sandbox settings, specific " Real-time protection " features often require manual activation or specific configuration within the Malware Protection profile before being pushed; they are not necessarily " automatically " active in the absolute default state without a profile assignment.

ZTNA tags (D): ZTNA tags are dynamic security posture attributes. While FortiSASE evaluates the endpoint to determine which tags apply, the tags themselves are not " pushed " to the client as a setting; rather, the ZTNA connection rules are pushed, and the tags are synchronized back to the security fabric for posture enforcement.

FortiSASE uses the following components for application control to act as an inline-CASB (Cloud Access Security Broker):

SSL Deep Inspection:

SSL deep inspection is essential for decrypting and inspecting HTTPS traffic to identify and control applications and data transfers within encrypted traffic.

This allows FortiSASE to enforce security policies on SSL/TLS encrypted traffic, providing visibility and control over cloud applications.

Web Filter with Inline-CASB:

The web filter component integrates with inline-CASB to monitor and control access to cloud applications based on predefined security policies.

This combination provides granular control over cloud application usage, ensuring compliance with security policies and preventing unauthorized data transfers.

FortiSASE Secure Private Access (SPA) provides flexible connectivity to internal corporate resources using a hub-and-spoke architecture where FortiSASE PoPs act as spokes to an organization ' s FortiGate hub.

Flow from Agent-based users to Private Resources (C): This is the core functionality of SPA. Remote users running FortiClient (agent-based) connect to the nearest FortiSASE PoP. The PoP, integrated into the corporate SD-WAN fabric, uses IPsec and BGP to route traffic to the private applications located behind the FortiGate hub or associated spokes.

Flow from Thin Branches/Branch On-ramp to Private Resources (E): FortiSASE extends its security and connectivity to physical locations through " Thin Edge " (e.g., FortiExtender, FortiAP) or " Branch On-ramp " (e.g., branch FortiGates). These sites form tunnels to the FortiSASE PoP, which then provides them with access to the same private resources in the SD-WAN network as the remote agent-based users.

Flow from Private Resources to Agent-based users (A): The SPA architecture is designed for bidirectional communication. Documentation confirms that traffic can be initiated from the FortiGate hub (or local networks behind it) to the remote VPN agents. This " Server-to-Client " flow is essential for administrative tasks, log forwarding, or real-time communication applications like VoIP.

Incorrect Options:

Option B: Traffic from private resources to the internet is handled via Secure Internet Access (SIA) or local gateway policies, not the SPA use case, which is dedicated to internal private application access.

Option D: While FortiSASE can facilitate branch-to-branch communication via ADVPN shortcuts, the term " SPA " specifically refers to the access layer for users and is not used to describe resource-to-resource or hub-to-hub traffic.

In FortiSASE, the Software Installations page (located under Network > Managed Endpoints ) provides a centralized view of all software inventory reported by the FortiClient agents. This feature is essential for administrators to maintain visibility into the environment and identify potentially unwanted applications (PUA) or unauthorized software installed on remote devices.

Software Inventory Reporting: FortiClient sends the endpoint ' s software inventory to FortiSASE upon initial registration and updates the portal whenever a change—such as an installation, update, or removal—occurs on the endpoint.

Available Information (Vendor): When viewing the global list of applications, the portal displays detailed metadata for each software entry. This includes the Vendor of the software and its specific version, allowing administrators to differentiate between reputable enterprise applications and suspicious third-party utilities.

Available Information (Endpoint Association): The interface includes an Endpoint Count field that indicates how many devices have a specific application installed. By selecting a specific application and using the View Endpoints action, the administrator can see a list of every individual endpoint where that software is currently active.

Incorrect Options: While license management is a general feature of the ecosystem, the Software Installations page itself does not track the license status of individual third-party applications (Option B). Similarly, while FortiSASE monitors traffic, the Software Installations inventory page does not report on the usage frequency (how often a user opens or uses the app) of the installed binaries (Option D).

By leveraging this inventory, administrators can proactively manage risk by identifying endpoints that possess high-risk software and taking remediation steps or applying ZTNA posture tags based on the presence of specific unauthorized software.

In a FortiSASE environment, the Unified FortiClient agent is the critical component that fulfills the requirement for " always-on " connectivity and security for remote users.

Persistent Encrypted Tunnels : The Unified FortiClient maintains a persistent, always-on connection to the FortiSASE infrastructure. 4 This is typically achieved through an auto-connect VPN tunnel (SSL or IPsec) that initiates as soon as the user logs into their device and has internet access.

Continuous Security Enforcement : By staying connected to a nearby FortiSASE Point of Presence (PoP), the endpoint ensures that all traffic is inspected. This allows the organization to enforce a consistent security posture—including Web Filtering, Antivirus, and Application Control—regardless of whether the user is at home, in a coffee shop, or traveling.

Zero-Trust Integration : Beyond simple connectivity, the unified agent supports Universal ZTNA . It continuously verifies the identity of the user and the security posture of the device before granting access to specific applications, thereby satisfying modern zero-trust security mandates.

Comparison of Other Components :

SD-WAN on-ramp (B) : Used primarily to integrate existing branch office SD-WAN networks with the SASE cloud for private application access.

Secure Web Gateway (C) : While a feature of the SASE PoP, the agentless SWG deployment (using PAC files) does not provide the same level of " always-on " persistent tunnel protection as the FortiClient agent.

Thin-branch SASE extension (D) : Focused on securing small branch locations (using FortiAP or FortiExtender) where individual client agents may not be deployed on every device.

In the user connection monitor, the random characters shown for the username indicate that log anonymization is enabled. Log anonymization is a feature that hides the actual user information in the logs for privacy and security reasons. To display proper user information, you need to disable log anonymization.

Log Anonymization:

When log anonymization is turned on, the actual usernames are replaced with random characters to protect user privacy.

This feature can be beneficial in certain environments but can cause issues when detailed user monitoring is required.

Disabling Log Anonymization:

Navigate to the FortiSASE settings.

Locate the log settings section.

Disable the log anonymization feature to ensure that actual usernames are displayed in the logs and user connection monitors.

Based on the detailed analysis of the provided exhibits ( image_65feb6.jpg ), the connectivity failure is caused by a mismatch in the Hub firewall policy configuration.

Endpoint Analysis: The Network Diagram shows the FortiClient endpoint has an IP address of 100.65.80.2/20 and currently carries the FortiSASE-Compliant ZTNA tag.

FortiSASE Policy Validation: The Private access policy on FortiSASE shows an " Accept " rule for traffic originating from " FortiSASE-Compliant " sources destined for " All Private Access Traffic " . This confirms the traffic is successfully leaving the FortiSASE PoP.

Routing Validation: The Learned BGP Routes on FortiSASE table shows the prefix 10.160.160.0/24 (the Server subnet) is correctly received via Next Hop 10.11.11.1 . Routing is correctly established.

Hub Firewall Policy Error: Examining the Hub firewall policy (edit 7), the srcaddr is set to " SASE_Remote_Access " . Looking at the address object definition for " SASE_Remote_Access, " it is configured with the subnet 10.11.11.0 255.255.255.0 .

The Conflict: The FortiClient ' s actual IP address ( 100.65.80.2 ) does not fall within the 10.11.11.0/24 range defined in the policy ' s source address. On a FortiGate hub, for traffic to be permitted through the tunnel to the internal server, the firewall policy must include the specific subnet assigned to the remote clients, not just the tunnel interface subnet. Because the FortiClient address range is missing from the hub ' s policy, the traffic is dropped at the hub.

FortiSASE utilizes Security Assertion Markup Language (SAML) to provide a seamless Single Sign-On (SSO) experience for remote users connecting to the cloud infrastructure.

Role Identification: In a SAML exchange, FortiSASE functions as the Service Provider (SP) . It relies on an external Identity Provider (IdP) —such as Microsoft Entra ID (formerly Azure AD), Okta, or FortiAuthenticator—to authenticate the user ' s identity and provide security assertions. 2

SAML Group Matching: One of the core features of the FortiSASE SAML implementation is the ability to perform group matching . During the authentication process, the IdP sends a SAML assertion that typically includes an " Attribute Statement " containing the user ' s group memberships. 3 FortiSASE captures this attribute and matches it against locally defined SAML user groups.

Policy Enforcement: This group matching capability is critical because it allows administrators to apply different Security Internet Access (SIA) or Secure Private Access (SPA) policies based on the user ' s role (e.g., " Marketing " vs. " Finance " ) rather than managing individual users manually.

Analysis of Incorrect Options: * Options C and D are incorrect because FortiSASE does not natively act as a SAML IdP; it is designed to consume assertions from professional identity management platforms.

Option B is incorrect because FortiSASE fully supports and relies upon group matching for enterprise-scale policy management.

The core of this issue lies in the difference between Certificate Inspection and Deep SSL Inspection within the FortiSASE security framework.

The Limitation of Certificate Inspection: When " Force Certificate Inspection " is enabled in a FortiSASE firewall policy, the system only inspects the SSL handshake—specifically the SNI (Server Name Indication) and certificate headers. It does not decrypt the actual data payload of the HTTPS session.

Antivirus Scanning Requirements: To detect and block malicious files like the EICAR test file when they are downloaded over an encrypted HTTPS connection (such as https://eicar.org), the FortiSASE antivirus engine must be able to " see " inside the encrypted tunnel. This requires Deep Inspection (Full SSL Inspection), where FortiSASE acts as a " man-in-the-middle " to decrypt, scan, and then re-encrypt the traffic.

Exhibit Analysis: The Secure Internet Access policy exhibit clearly shows the toggle for Force Certificate Inspection is enabled (set to " ON " ). As specified in the Fortinet technical documentation, enabling this option forces the policy to use Certificate Inspection only, overriding any Deep Inspection settings that might be defined in the Profile Group.

Conclusion: Because the traffic is only undergoing certificate-level inspection, the antivirus engine cannot analyze the encrypted eicar.com-zip file payload, allowing the download to proceed even though an antivirus profile is active in the group.

The VPN tunnel between the FortiSASE spoke and the FortiGate hub is not establishing due to the configuration of mode config, which is not supported by FortiSASE spoke devices. Mode config is used to assign IP addresses to VPN clients dynamically, but this feature is not applicable to FortiSASE spokes.

Mode Config in IPsec:

The configuration snippet shows that mode config is enabled in the IPsec phase 1 settings.

Mode config is typically used for VPN clients to dynamically receive an IP address from the VPN server, but it is not suitable for site-to-site VPN configurations involving FortiSASE spokes.

Configuration Adjustment:

To establish the VPN tunnel, you need to disable mode config in the IPsec phase 1 settings.

This adjustment will allow the FortiSASE spoke to properly establish the VPN tunnel with the FortiGate hub.

Steps to Disable Mode Config:

Access the VPN configuration on the FortiSASE spoke.

Edit the IPsec phase 1 settings to disable mode config.

Ensure other settings such as pre-shared key, remote gateway, and BGP configurations are correct and consistent with the FortiGate hub.

SSL deep inspection (DPI) is a critical security function that allows FortiSASE to decrypt and inspect the actual payload of encrypted traffic (such as HTTPS, SMTPS, and FTPS) to identify and block hidden threats.

The Role of the CA: For this process to occur, FortiSASE must act as a " man-in-the-middle " by intercepting the SSL session, decrypting it for inspection, and then re-encrypting it before sending it to the endpoint. 2 To re-encrypt the traffic, FortiSASE acts as a Certificate Authority (CA) and signs a new certificate for the destination website on the fly.

Certificate Types: This CA role can be fulfilled using the default self-signed certificate provided by Fortinet (typically Fortinet_CA_SSL) or a certificate issued by an organization ' s internal/private CA . Publicly trusted third-party CAs (like DigiCert or Let ' s Encrypt) do not sell CA-capable certificates that can be used for this type of inspection.

Client Machine Requirement: Because the endpoint’s browser or operating system will not natively trust a certificate signed by a private or self-signed CA, the root CA certificate must be imported into the Trusted Root Certification Authorities store on all managed client machines. Failure to do so results in persistent certificate warnings or blocked connections for the end user.

Supported Features: Once enabled, SSL deep inspection provides the necessary visibility for high-level security features to function, including Antivirus , Web Filtering , Data Loss Prevention (DLP) , File Filter , and Application Control .

When deploying FortiSASE agent-based clients, several features are available that are not typically available with an agentless solution. These features enhance the security and management capabilities for endpoints.

Vulnerability Scan:

Agent-based clients can perform vulnerability scans on endpoints to identify and remediate security weaknesses.

This proactive approach helps to ensure that endpoints are secure and compliant with security policies.

SSL Inspection:

Agent-based clients can perform SSL inspection to decrypt and inspect encrypted traffic for threats.

This feature is critical for detecting malicious activities hidden within SSL/TLS encrypted traffic.

Web Filter:

Web filtering is a key feature available with agent-based clients, allowing administrators to control and monitor web access.

This feature helps enforce acceptable use policies and protect users from web-based threats.

Based on the provided exhibits, the reason why the Win7-Pro endpoint can no longer access the internet through FortiSASE is due to exceeding the total vulnerability detected threshold. This threshold is used to determine if a device is compliant with the security requirements to access the network.

Endpoint Compliance:

FortiSASE monitors endpoint compliance by assessing various security parameters, including the number of vulnerabilities detected on the device.

The compliance status is indicated by the ZTNA tags and the vulnerabilities detected.

Vulnerability Threshold:

The exhibit shows that Win7-Pro has 176 vulnerabilities detected, whereas Win10-Pro has 140 vulnerabilities.

If the endpoint exceeds a predefined vulnerability threshold, it may be restricted from accessing the network to ensure overall network security.

Impact on Network Access:

Since Win7-Pro has exceeded the vulnerability threshold, it is marked as non-compliant and subsequently loses internet access through FortiSASE.

The FortiSASE endpoint profile enforces this compliance check to prevent potentially vulnerable devices from accessing the internet.

Based on the provided exhibits and the logic of FortiSASE On/off-net detection , the endpoint ' s behavior is determined by its network environment relative to the configured rules.

Subnet Matching and Detection: The On-net rule set (named " On-Premises " ) is configured to identify a trusted location when the endpoint " Connects from a known local subnet " . The administrator has defined the known subnet as $192.168.13.0/24$ . Since the endpoint ' s IP address is $192.168.13.101$ , it falls within this range. Consequently, FortiClient detects the endpoint as being on-net (on-fabric).

Action Logic (Exemption): In a FortiSASE Endpoint Profile , when On/off-net detection is enabled and an endpoint matches an " On-net " rule, the standard behavior is to exempt the endpoint from auto-connecting to the FortiSASE VPN tunnel. This design assumes the endpoint is already in a secured office environment where the corporate firewall (FortiGate) provides the necessary protection, making the SASE tunnel redundant.

Comparison of Other Options: * Option B: Incorrect, because the IP matches the defined " known local subnet " rule for on-net detection.

Option D: Incorrect, as auto-connect only triggers when the endpoint is detected as off-net to ensure remote security.

In FortiSASE, Zero Trust Network Access (ZTNA) tags—also known as security posture tags—are used to dynamically grant or deny access based on the real-time security state of an endpoint. This mechanism ensures that only devices meeting specific compliance requirements can access protected resources or the internet.

Endpoint Analysis: The Managed Endpoints exhibit shows that while Jumpbox only has the FortiSASE-Compliant tag, the Windows-AD endpoint has been assigned both FortiSASE-Compliant and FortiSASE-Non-Compliant tags. This indicates that a security posture check on the Windows-AD device has failed, triggering a rule that applies the non-compliant tag.

Policy Evaluation: The Secure Internet Access Policy table shows two custom policies. The first policy, named Non-compliant , uses the FortiSASE-Non-Compliant tag as its source and has the action set to Deny . The second policy, Web Traffic , allows access for FortiSASE-Compliant users.

Root Cause of Outage: Because FortiSASE (powered by FortiOS) processes security policies in a top-down sequence, the " Non-compliant " policy is evaluated first. Since Windows-AD matches the source criteria for this " Deny " policy, its traffic is blocked before it can reach the " Accept " policy.

Although the exhibit shows a warning icon for the FortiClient version on Windows-AD, the direct cause of the internet outage is the explicit Deny policy triggered by the change in the device ' s security posture (the application of the Non-Compliant tag).