Fortinet NSE 7 OT Security 7.2 - NSE7_OTS-7.2 Practice Questions

Explanation:

In this Purdue Model Level 1 deployment:
PLC1 and PLC2 are in different VLANs for segmentation.
A Layer 2 switch connects them with access ports for each PLC and a trunk port to FortiGate.
Since VLANs are isolated at Layer 2, inter-VLAN traffic must be routed.
The FortiGate at Level 2 acts as the router/firewall for inter-VLAN traffic.

Therefore, traffic between PLC1 and PLC2 must go:
PLC1 → Switch (access VLAN A) → Trunk to FortiGate → FortiGate routes/filters → Trunk back to Switch → PLC2 (access VLAN B).

Why other options are incorrect:

A. The Layer 2 switch rewrites VLAN tags before sending traffic to the FortiGate device.
→ Incorrect. A Layer 2 switch forwards frames with existing VLAN tags intact on trunk ports; it does not rewrite tags unless explicitly configured for VLAN translation (uncommon in OT).

B. The Layer 2 switches routes any traffic to the FortiGate device through an Ethernet link.
→ Incorrect. A Layer 2 switch does not route; it forwards frames based on MAC addresses. Routing is performed by FortiGate.

D. In order to communicate, PLC1 must be in the same VLAN as PLC2.
→ Contradicts the scenario. They are in different VLANs, and communication is enabled via routing through FortiGate, not same-VLAN adjacency.

Reference:
Fortinet OT Security design guides recommend using FortiGate as the inter-VLAN router/firewall in Purdue Level 1/2 to enforce segmentation and inspection between OT devices (FortiOS OT Security Deployment Guide).

Explanation:
In FortiGate/FortiOS OT device detection and profiling (Device Identification & IoT/OT Detection), when device profiling rules are enabled, FortiGate continuously scans the network and only applies the profiling rules to devices classified as “rogue” (i.e., unknown or untrusted devices). Trusted/known devices are not re-evaluated by profiling rules unless manually reset.

Correct Option:

C. Rogue devices, only when they connect for the first time
FortiGate applies device profiling rules exclusively to rogue (unknown) devices during their initial discovery and fingerprinting process. Once the device is identified and moved to the known/trusted list (automatically or manually), it is no longer subject to repeated profiling rule evaluation.

Incorrect Option:

A. Known trusted devices, each time they change location
Known/trusted devices are exempt from profiling rules. Location changes do not trigger re-profiling.

B. All connected devices, each time they connect
Profiling rules are not applied to every device on every connection; only rogue devices are evaluated, and only once during initial detection.

D. Rogue devices, each time they connect
Even rogue devices are profiled only the first time they are detected. Subsequent connections of the same rogue device use the previously determined profile unless the entry is cleared.

Reference:
NSE 7 OT Security 7.2 Study Guide – Section “OT Device Detection and Profiling” (Device Identification > Profiling Rules)

Explanation:

To enable VPN access for supervisors at both the Branch and HQ sites using the same soft FortiToken, you must implement centralized token management. FortiGate devices do not support sharing a single FortiToken across multiple FortiGates natively. The correct solution is to deploy FortiAuthenticator, which acts as a centralized authentication server and token authority.

FortiAuthenticator allows:
Centralized management of FortiTokens (hardware or soft tokens)
Integration with multiple FortiGate VPN gateways
RADIUS or LDAP-based authentication with FortiToken OTP
Seamless user experience across distributed sites
This setup ensures that the same user and token can authenticate to both VPN gateways without duplicating token registration or compromising security.

Why Other Options Are Incorrect:

B. Register the same FortiToken on more than one FortiGate Not supported.
FortiTokens are bound to a specific FortiGate unless managed centrally via FortiAuthenticator.

C. Use the user self-registration server Irrelevant.
Self-registration is for onboarding users, not for sharing tokens across gateways.

D. Use a third-party RADIUS OTP server Possible but not required.
FortiAuthenticator is purpose-built for FortiToken integration and preferred for Fortinet environments.

References:
Fortinet FortiAuthenticator Admin Guide – Token Management and VPN Integration
Fortinet Knowledge Base – Using FortiAuthenticator for centralized FortiToken OTP across multiple FortiGates

Explanation:

FortiSIEM's incident investigation follows a structured workflow. The Overview dashboard provides the initial high-level context with visual widgets showing event spikes, top attackers, and geographic anomalies over the past 24 hours. From there, analysts pivot to the Risk view, which displays correlated security incidents prioritized by risk score—crucial for identifying OT-specific rule violations like unauthorized PLC access. Finally, the List view enables granular forensic analysis, allowing filtering by OT assets, protocols (Modbus/DNP3), and raw log details to determine root cause.

Why other options are incorrect:

A. Security:
Not a primary investigative pane in FortiSIEM's analyst workflow. While security events are analyzed, the interface uses Overview→Risk→List for structured investigation.

B. IPS:
This is an event source type, not an investigative interface. IPS logs appear in the List view and may trigger Risk incidents but aren't a navigation option themselves.

Reference:
FortiSIEM Analyst Guide emphasizes this three-pane methodology: "Use Overview for situational awareness, Risk for prioritized incidents, and List for event details" (FortiSIEM 6.4 Analyst Guide, Chapter 3: Investigating Events).

Explanation:

A. You must set correct operator in event handler to trigger an event.
In FortiSoC, event handlers rely on logical operators (AND, OR, etc.) to determine when conditions are met. If the operator is misconfigured, the event won’t trigger properly. This is fundamental to building reliable detection logic in FortiAnalyzer SOC modules.

B. You can automate SOC tasks through playbooks.
FortiAnalyzer SOAR (Security Orchestration, Automation, and Response) allows administrators to automate repetitive SOC tasks. Playbooks are central to SOAR, enabling automated workflows such as blocking IPs, quarantining endpoints, or escalating incidents. This is a key feature of FortiAnalyzer’s FortiSoC module.

❌ Why the Other Options Are Wrong

C. Each playbook can include multiple triggers. Incorrect.
A playbook in FortiAnalyzer SOAR has one trigger (e.g., an event or alert) that starts the workflow. Multiple actions can follow, but triggers are singular per playbook.

D. You cannot use Windows and Linux hosts security events with FortiSoC.
Incorrect. FortiSoC can ingest and correlate events from multiple sources, including Windows and Linux host logs, via connectors or syslog. Limiting it to exclude host events is false.

📖 Reference
Fortinet FortiAnalyzer Administration Guide – FortiSoC and SOAR features
Fortinet NSE Training (NSE7 OT Security) – SOAR playbooks and event handler configuration

Explanation:

Threat hunting reports in FortiSIEM are specifically designed for proactive exploration of indicators of compromise (IOCs) and advanced attack patterns across network devices. When investigating threats that exploit vulnerabilities in router, switch, and firewall firmware images, these reports allow analysts to search for:

Unexpected firmware modification attempts
Unauthorized configuration changes
Exploit patterns matching known CVEs in network device firmware
Anomalous traffic to/from management interfaces of these devices
Threat hunting reports use advanced querying, behavioral analytics, and threat intelligence feeds to identify sophisticated exploit activities that evade traditional signature-based detection.

Why other options are incorrect:

A. CMDB reports:
Focus on configuration management and asset inventory, not exploit detection.

C. Compliance reports:
Validate adherence to regulatory standards (NIST, IEC 62443), not active threat exploration.

D. OT/IoT reports:
Specialize in operational technology and IoT device behaviors/protocols, not necessarily firmware exploits across generic network infrastructure.

Reference:
FortiSIEM Analyst Guide notes "Threat Hunting reports enable security teams to proactively search for malicious activity using custom queries and threat intelligence" – particularly relevant for firmware-level attacks that bypass conventional security controls (FortiSIEM 6.4 Admin Guide, Chapter: Advanced Analytics).

Explanation:

CMDB operational reports in FortiSIEM provide continuous monitoring and alerting on device health and performance metrics, making them the primary tool for identifying device failures. These reports analyze real-time and historical operational data from network devices—such as CPU/memory utilization, interface errors, temperature thresholds, and availability status—to detect failures or performance degradation that could put the OT network at risk.

Why other options are incorrect:

A. Business service reports:
Focus on service-level availability and performance from an application/user perspective, not individual device failures.

B. Device inventory reports:
Provide static asset information and configuration details, not real-time failure monitoring.

D. Active dependent rules reports:
Display status of correlation rules, not physical/logical device performance metrics.

Reference:
FortiSIEM Administration Guide specifies that "CMDB operational reports monitor device health metrics and generate alerts for performance thresholds," directly supporting OT network analysts in proactive failure identification (FortiSIEM 6.4 Admin Guide, Chapter: Configuration and Operational Reports).