NSE4 Security Profiles Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The application signatures for Facebook and Twitter are not up to date

  Why it's wrong here

  Outdated signatures are rarely the culprit because FortiGuard pushes regular updates for major applications like Facebook and Twitter, and the FortiGate would typically show an error if the signature database is stale. Even with a fully current signature database, application control cannot inspect TLS-encrypted payloads unless the SSL/SSH inspection profile is set to deep-inspection. In certificate-inspection mode, the FortiGate only sees the server certificate and the SNI field, so it cannot match application signatures against the decrypted HTTP content, making the signature version irrelevant to the failure.

• ✓

  The firewall policy has SSL/SSH inspection set to 'certificate-inspection' instead of 'deep-inspection'

  Why this is correct

  The correct reason for the failure is that the firewall policy uses certificate-inspection instead of deep-inspection. In certificate-inspection mode, the FortiGate validates the server certificate but does not decrypt the HTTPS payload, so the application control engine is blind to the actual web requests and cannot identify Facebook or Twitter traffic. Deep-inspection performs a man-in-the-middle decryption by presenting a generated CA certificate to the client, decrypting the session, scanning the content with application control and other security profiles, then re-encrypting the traffic. Without deep-inspection, application control can at best rely on incomplete heuristics like SNI, which is often insufficient for modern applications that use encrypted transports or certificate pinning.

• ✗

  The application control profile is set to 'monitor' instead of 'block'

  Why it's wrong here

  Setting the application control profile to monitor would cause the firewall to allow the traffic and log an entry that the application was detected, but the administrator would see the application in the logs with an 'allow' or 'monitor' action. The symptom in this scenario is that the applications are not blocked at all, but it is also likely that the administrator cannot see Facebook or Twitter in the application control logs because the traffic is not being decrypted. Monitor mode only affects the action taken after detection; it does not prevent detection. Therefore, while monitor is a possible reason for not blocking, it cannot explain why the application signatures are never matched in the first place, which is the typical symptom when certificate-inspection is used.

• ✗

  The firewall policy is configured with flow-based inspection

  Why it's wrong here

  Flow-based inspection is not the problem because FortiGate's flow-based inspection engine supports application control and can still identify applications when combined with deep-inspection. In flow-based mode, the FortiGate processes packets in real time and uses the IPS engine to match application signatures, which works fine with SSL deep inspection. The real determinant is the SSL/SSH inspection profile, not the inspection mode, because without deep-inspection, neither flow-based nor proxy-based processing can see the decrypted payload. Thus, configuring the firewall policy with flow-based inspection is not an inherent limitation; it only changes the performance characteristics and how packets are handled, not the ability to decrypt and inspect HTTPS traffic.

Go deeper

Related to this question