Fortinet FCSS - FortiSASE 24 Administrator - FCSS_SASE_AD-24 Practice Questions

Summary:
The EICAR test file is a known threat that should be blocked by the Antivirus profile. However, the logs show the download from www.eicar.org was allowed. The key detail is that the traffic is HTTPS. For Antivirus to scan the content of an encrypted HTTPS connection, it must first be decrypted. The configuration preventing this is found in the "Secure Internet Access policy" exhibit.

Correct Option:

C. The HTTPS protocol is not enabled in the antivirus profile.
The "Security Profile Group" exhibit shows the "Inspected Protocols" for Antivirus. The list includes HTTP, SMTP, POP3, etc., but notably does not include HTTPS. For Antivirus to scan and block a file download from an HTTPS website, the HTTPS protocol must be explicitly selected for inspection. Since it is not, the encrypted traffic passes through without being scanned by the antivirus engine, allowing the download.

Incorrect Option:

A. Web filter is allowing the traffic.
The Web Filter did allow the traffic, but this is a symptom, not the root cause. The Web Filter correctly allowed the "Information and Computer Security" category. The failure lies with the Antivirus profile, which is responsible for detecting and blocking the malicious file inside the allowed web traffic.

B. IPS is disabled in the security profile group.
The IPS profile is set to "Recommended," which means it is active. Furthermore, the EICAR file is primarily a test for Antivirus, not IPS. While some IPS signatures might detect it, the primary and intended method of blocking it is via the Antivirus profile.

D. Force certificate inspection is enabled in the policy.
The policy exhibit shows that "Force Certificate Inspection" is not enabled (the checkbox is empty). Even if it were, "Certificate Inspection" is a basic inspection mode that does not decrypt traffic. It only validates the server certificate. Blocking the file requires Deep Inspection, which is configured in the SSL Inspection profile, not the policy action.

Reference:
Fortinet Documentation Library: FortiGate Administration Guide - Antivirus (This explains how antivirus profiles require the correct protocols to be selected for inspection, which is a core concept shared with FortiSASE).

Summary:
During the initial setup of FortiSASE, the administrator must choose the primary geographic regions for core service components. This is a foundational step that determines where critical functions like user authentication, security processing, and log storage will be physically hosted, impacting performance and compliance.

Correct Option:

B. Points of presence:
The administrator must select primary and secondary Security PoPs. These are the locations where user traffic will be routed for security inspection (SWG, CASB, etc.). This choice directly impacts latency and performance for users.

D. Logging:
A location for log storage and reporting must be selected. This determines the geographic region where all traffic, threat, and event logs generated by FortiSASE will be stored and processed for reports.

E. Authentication:
The administrator must choose a region for the identity and access management (IAM) service. This component handles user authentication requests, and its location can affect login times and must align with data residency requirements.

Incorrect Option:

A. Endpoint management:
Endpoint management for FortiSASE is handled by the unified FortiClient agent and its connection to the FortiSASE cloud. The administrator does not select a separate, specific data center location for this component during the initial portal setup; it is inherent to the PoP and service selection.

C. SD-WAN hub:
While FortiSASE uses SD-WAN technology to connect to customer hubs, the SD-WAN hub itself refers to the customer's on-premises FortiGate device. The customer hub location is not selected within the FortiSASE portal; it is a pre-existing part of the customer's network that is registered with FortiSASE.

Reference:
Fortinet Documentation Library: FortiSASE Administration Guide - Initial Configuration (This guide outlines the initial setup steps, including selecting regions for core services).

Summary:
The question asks for the use case that reduces the need to configure each endpoint individually. This points toward a solution that does not require installing and managing a dedicated security agent on every device. A clientless or agentless approach achieves this by leveraging standard browser capabilities for secure access.

Correct Option:

B. Agentless remote user internet access
This use case minimizes endpoint configuration because it does not require installing the FortiClient agent. Users typically access security by configuring their browser or operating system to use the FortiSASE Secure Web Gateway (SWG) as a proxy, often via a Proxy Auto-Configuration (PAC) file. This method centralizes the configuration management on FortiSASE, with minimal setup required on the endpoint itself.

Incorrect Option:

A. Site-based remote user internet access
This refers to securing an entire remote site (like a branch office) by connecting a FortiGate to FortiSASE. It secures the site's traffic but does not specifically address the configuration burden of individual, roaming endpoints.

C. SIA for SSL VPN remote users
This use case involves users connecting via a traditional SSL VPN, which often requires a VPN client (like FortiClient) to be installed and configured on the endpoint. This increases, rather than minimizes, the individual endpoint configuration.

D. SIA using ZTNA
Zero Trust Network Access (ZTNA) for application access typically requires the FortiClient agent to be installed on the endpoint to assess device posture (ZTNA tags) and establish secure, granular tunnels. This is an agent-based model, not an agentless one.

Reference:
Fortinet Documentation Library: FortiSASE Solution Guide - Clientless Access (This document describes the agentless access method, which aligns with minimizing endpoint configuration).

Explanation:
FortiSASE offers a Log Anonymization feature to protect personally identifiable user information (like usernames) in logs, dashboards, and reports. This process is accomplished by hashing the user data rather than simply encrypting it. Specifically, FortiSASE employs a secure hashing method that includes the use of a salt. The salt is a random value added to the input (the username) before it is hashed. This prevents identical usernames from generating the same hash, significantly increasing security and preventing the use of rainbow tables for reverse-lookup.

Correct Option:

B. By hashing data using salt
FortiSASE uses a security best practice of salting the input (the username) before running it through a cryptographic hash function.

Hashing (an irreversible one-way process) converts the original username into a fixed-length string of characters, effectively hiding the actual identity.

The salt ensures that even if two users have the same name, the resulting hash in the log will be different, adding an essential layer of protection against attacks that rely on pre-calculated hash values.
Incorrect Option:

A. By hashing data using Blowfish
Blowfish is a symmetric-key block cipher used for encryption, not primarily for one-way logging hashes, though it can be used for password hashing. Fortinet uses a standard salting mechanism with a cryptographic hash, not this specific algorithm for log anonymization.

C. By encrypting data using Secure Hash Algorithm 256-bit (SHA-256)
SHA-256 is a modern, strong hashing algorithm, and it is likely the hash function used. However, the option states "By encrypting data", which is incorrect terminology. Hashing is a one-way transformation, not an encryption (which is a two-way, reversible process). The use of salt is the crucial additional detail for log anonymization.

D. By encrypting data using advanced encryption standard (AES)
AES is the industry standard for symmetric-key encryption, a two-way process that is easily reversible with the correct key. The purpose of log anonymization is to make the user data irreversible for privacy, thus encryption is the wrong method.

Reference:
Fortinet FortiSASE Administration Guide – Analytics and Logging sections, which discuss the Log Anonymization feature and the methodology used to protect user data (hashing with salt).

Explanation:
Traffic from a FortiClient endpoint to FortiSASE for Secure Internet Access (SIA) is transported over a ZTNA-based or SSL-based VPN tunnel. Before FortiSASE can apply SWG or other security policies, the client-to-cloud tunnel must first be established. This connection is governed by a VPN policy, which controls and secures the initial traffic flow from the endpoint into the SASE fabric.

Correct Option:

A – VPN policy
A VPN policy governs how FortiClient endpoints authenticate and tunnel traffic to FortiSASE. This policy defines encryption, tunnel behavior, and permitted endpoint connectivity. Without a VPN policy, the endpoint cannot send traffic to the SASE cloud for inspection. Therefore, it is the correct policy type for controlling endpoint-to-FortiSASE traffic in an SIA deployment.

Incorrect Options:

B. Thin edge policy
Thin edge policies are used for branch devices or thin-edge CPE deployments, not for remote endpoints connecting via FortiClient. These policies manage traffic from site devices toward FortiSASE, not individual remote users, so they do not apply to SIA endpoint traffic.

C. Private access policy
Private access policies are used for ZTNA/zero-trust access to internal private applications hosted in data centers or clouds. They are not used for public internet-bound Secure Web Gateway (SWG) traffic and do not control endpoint-to-SASE internet access.

D. Secure web gateway (SWG) policy
SWG policies apply after the endpoint traffic reaches FortiSASE. They control inspection and filtering of internet-bound traffic, not the initial client-to-FortiSASE tunnel. They cannot manage or establish the endpoint’s connectivity channel, making them incorrect for this question.

Reference:
Fortinet Documentation – FortiSASE Secure Internet Access Architecture → Endpoint Onboarding Using FortiClient VPN Policies.

Explanation:
To inspect all endpoint traffic while excluding specific applications (such as Google Maps), FortiSASE supports split tunneling. Split tunneling allows administrators to specify destinations that should bypass the FortiSASE VPN tunnel and instead use the local physical interface. By configuring Google Maps as a split-tunnel destination in the endpoint profile, FortiSASE inspects all other traffic while allowing Google Maps to exit locally.

Correct Option:

C – Configure the Google Maps FQDN as a split-tunneling destination on the FortiSASE endpoint profile.
This configuration ensures that all traffic except Google Maps is routed through the FortiSASE VPN tunnel for inspection. Google Maps traffic, identified by FQDN, is excluded and sent directly out of the endpoint’s physical interface. This satisfies both requirements: full inspection of all general internet traffic and an exemption specifically for Google Maps.

Incorrect Options:

A. Exempt the Google Maps FQDN from the endpoint system proxy settings.
Proxy exemptions do not control VPN routing or tunnel behavior. Even if Google Maps is excluded from proxy settings, the traffic would still be routed through the VPN unless split tunneling is applied. This option does not meet the requirement to route Google Maps traffic directly out of the physical interface.

B. Configure a static route with the Google Maps FQDN on the endpoint to redirect traffic.
Static routes cannot be applied to FQDNs, only to IP addresses or subnets. Additionally, Google Maps uses a large and dynamic range of IPs, making static routing impossible and unreliable. This approach does not provide proper redirection or tunnel exclusion.

D. Change the default DNS server configuration on FortiSASE to use the endpoint system DNS.
DNS settings determine hostname resolution but have no direct impact on VPN tunnel routing. Changing the DNS server does not achieve traffic exclusion, nor does it redirect Google Maps traffic.

Reference:
Fortinet Documentation – FortiSASE Endpoint Profiles → Split Tunneling Configuration and FortiClient EMS Administration Guide → Excluding Domains from VPN Tunnel.

Explanation:
This scenario describes a hybrid ZTNA architecture where the security inspection and access control must occur on-premises on the customer's FortiGate, but the device posture assessment is managed from the cloud (FortiSASE). The goal is to use cloud-derived posture tags to inform on-premises ZTNA policies, allowing the FortiGate to process the TCP traffic.

Correct Option:

A. Configure ZTNA servers and ZTNA policies on FortiGate.
This defines the protected applications (ZTNA servers) and the access rules (ZTNA policies) on the FortiGate itself. These policies will reference tags to make allow/deny decisions for user traffic arriving at the proxy.

D. Configure FortiGate as a zero trust network access (ZTNA) access proxy.
This is the core on-premises enforcement point. The FortiGate must operate in ZTNA Access Proxy mode to terminate user connections, authenticate them, evaluate policies (using tags), and forward authorized traffic to the protected servers.

E. Sync ZTNA tags from FortiSASE to FortiGate.
This is the critical integration link. FortiSASE performs the device posture checks on remote endpoints and assigns compliance tags (e.g., FortiSASE-Compliant). These tags must be synchronized to the on-premises FortiGate so its local ZTNA policies can use them as matching criteria to grant or deny access.

Incorrect Option:

B. Configure private access policies on FortiSASE with ZTNA.
This would steer the traffic to be processed by FortiSASE in the cloud, not by the on-premises FortiGate as explicitly required. This setup is for cloud-enforced ZTNA to public or SaaS apps, or to private apps via a FortiSASE LAN extension.

C. Configure ZTNA tags on FortiGate.
Tags must be synced from FortiSASE, not manually configured locally. The FortiGate can define local tags, but the scenario requires using tags based on cloud-managed device posture checks, which originate from FortiSASE's Endpoint Posture Service.

Reference:
This describes the FortiSASE Hybrid ZTNA model, documented in Fortinet's solution guides. In this model, FortiSASE acts as the ZTNA Controller for posture assessment and tag assignment, while an on-premises FortiGate acts as the ZTNA Proxy (Access Proxy). Tags are synchronized via the Fabric Connector, allowing the FortiGate to enforce policies based on cloud-derived posture status.