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

Explanation:

port1 is a physical interface with IP 10.200.1.1/24.
port1‑vlan10 is a VLAN sub‑interface on port1 with VLAN ID 10 and IP 10.1.10.1/24.
port1‑vlan1 is a VLAN sub‑interface on port1 with VLAN ID 1 and IP 10.200.5.1/24.
Each of these interfaces operates in a separate broadcast domain because:
The physical interface port1 is an untagged Layer‑3 interface (no VLAN tagging), so its traffic is isolated from VLAN‑tagged traffic.
VLAN 10 and VLAN 1 are distinct VLANs; traffic is separated by 802.1Q tags. Thus, all three interfaces cannot directly exchange broadcast/multicast frames with each other.

Why other options are incorrect:

A. port2, port2‑vlan10, and port2‑vlan1 are part of the software switch interface.
→ False. The exhibit lists them as separate interfaces, not as members of a software‑switch. They are independent Layer‑3 interfaces/VLANs.

B. The VLAN ID of port1‑vlan1 can be changed to the VLAN ID 10.
→ Technically possible, but the statement is not a true description of the current configuration shown; it’s a hypothetical change, not a fact about the exhibit.

C. port1‑vlan10 and port2‑vlan10 are part of the same broadcast domain.
→ False. Even though both have VLAN ID 10, they are on different physical ports (port1 and port2). For them to share a broadcast domain, they must be connected via a common Layer‑2 switch or trunk—which isn’t indicated here. As configured, they are separate Layer‑3 interfaces with different IP subnets.

Reference:
FortiOS Interface Guide explains, “Physical interfaces and VLAN sub‑interfaces operate in separate broadcast domains unless explicitly bridged” (FortiOS 7.2, Interface Configuration chapter). VLANs on different physical ports remain isolated without Layer‑2 bridging.

Explanation:
FortiNAC primarily uses the RADIUS protocol for seamless integration with wireless networks, specifically to obtain the connecting client's MAC address and enforce network access control policies. When a wireless client attempts to connect to an Access Point (AP)/Controller, the AP/Controller acts as a Network Access Server (NAS). It forwards authentication requests, which contain the client's MAC address, to FortiNAC acting as the RADIUS server. This critical interaction allows FortiNAC to identify the device and apply the correct network policies (e.g., VLAN assignment).

Correct Option:

A. RADIUS
The RADIUS (Remote Authentication Dial-In User Service) protocol is the standardized method for Authentication, Authorization, and Accounting (AAA) in 802.1X and MAC Authentication Bypass (MAB) environments. When a device connects:

The Access Point (AP) sends a RADIUS Access-Request message to FortiNAC.

This message includes the client's MAC address in the Calling-Station-Id RADIUS attribute.

FortiNAC processes this request, uses the MAC address to look up the host in its database, determines its security posture, and returns an Access-Accept or Access-Reject with enforcement details (like VLAN ID) to the AP.

Incorrect Options:

B. Link traps:
Link traps (SNMP notifications) are primarily used to notify FortiNAC when an interface on a switch changes its state (e.g., linkUp or linkDown). While useful for wired port state monitoring, they do not inherently provide the specific client MAC address that is connecting on a wireless AP or controller, making them less suitable for the initial device identification in a wireless context.

C. End station traffic monitoring:
While FortiNAC can gather information by monitoring network traffic (e.g., DHCP, ARP) to profile devices, this is a passive method and is often a secondary or supplemental mechanism. For initial network access control and enforcement in a wireless setting, the active authentication/authorization process via RADIUS is the primary and most reliable method to obtain the connecting MAC address.

D. MAC notification traps:
Similar to general link traps, MAC notification traps (like newMacTrap) are often associated with wired switches informing the NAC system that a new MAC address has appeared on a port. However, FortiNAC is specifically configured to rely on the RADIUS exchange from wireless controllers/APs for host visibility, as the RADIUS messages contain the necessary MAC and authentication context.

Reference:
Fortinet Document Library - FortiNAC Wireless Integration Guides (Referencing the FortiNAC architecture for MAC and 802.1X authentication).

Explanation:

B. NAT is disabled in the FortiGate firewall policy from port3 to ssw-01.
For Modbus TCP to function correctly in this internal OT network, NAT should be disabled on the firewall policy between port3 and ssw-01. Modbus addressing often relies on explicit IPs, and NAT would break protocol integrity.

D. Port5 is not a member of the software switch.
The diagram shows port5 connected to PLC1 with a different subnet (10.10.4.1/24), while ssw-01 includes port3 (and possibly others) with subnet 10.10.3.254/24. For port5 to be in a different subnet, it cannot be a member of the same software switch ssw-01 (which operates as a single Layer‑2 segment).

Why other options are incorrect:

A. The FortiGate-Edge device must be in NAT mode.
→ False. "NAT mode" refers to the operational mode of FortiGate (NAT vs. Transparent). The device can be in NAT mode (routing) or Transparent mode (bridging) for this topology; the requirement is about NAT in policies, not the global mode.

C. The FortiGate device is in offline IDS mode.
→ Incorrect. Offline IDS uses SPAN/mirror ports for passive monitoring, but the diagram shows active routed interfaces (port3, port5, ssw-01) with IP addresses, indicating inline deployment.

Reference:
FortiOS Software Switch and Modbus deployment guides note: (1) software switch members share the same broadcast domain; (2) NAT should be disabled for industrial protocols to preserve addressing (FortiOS 7.2, Software Switch & OT Security chapters).

Explanation:
This scenario requires collecting and analyzing temperature data from remote industrial devices (fuel pumps) for centralized monitoring. The key is to place the data collection point (the "fuel server," likely a data historian or SCADA server) locally on the OT/remote network for reliable, low-latency data acquisition from the pumps. The analytics engine (FortiSIEM) should be placed centrally on the corporate network for secure, aggregated monitoring and alerting.

Correct Option:

C. Configure a fuel server on the remote network, and deploy a FortiSIEM with a single pattern temperature performance rule on the corporate network.
This architecture is correct. The local fuel server in the OT zone collects real-time operational data. FortiSIEM, deployed centrally, receives this data (via connectors/syslog) and uses a performance rule (not a security rule) to monitor metrics like temperature for fluctuations, generating alerts for the corporate monitoring team.

Incorrect Options:

A. Configure a fuel server on the remote network, and deploy a FortiSIEM with a single pattern temperature security rule on the corporate network.
This is incorrect because monitoring for temperature fluctuations is an operational performance or safety issue, not a security threat. FortiSIEM uses performance rules for metric-based threshold monitoring (e.g., temperature), not security rules, which are for event correlation related to attacks or policy violations.

B. Configure a fuel server on the corporate network, and deploy a FortiSIEM with a single pattern temperature performance rule on the remote network.
Placing the fuel server on the corporate network is inefficient and introduces latency and reliability issues for collecting real-time data from remote OT devices across potentially constrained network links. FortiSIEM should also be centrally located.

D. Configure both fuel server and FortiSIEM with a single-pattern temperature performance rule on the corporate network.
This is incorrect for two reasons: it wrongly places the data collection server away from the source devices, and it misapplies the performance rule configuration. The performance rule is configured within FortiSIEM itself, not on the external fuel server.

Reference:
Fortinet OT Security best practices and FortiSIEM administration guides emphasize segregating data collection (in the OT zone) from centralized analysis (in the IT zone). The distinction between performance rules (for metric monitoring) and security rules (for event correlation) is fundamental in FortiSIEM's role in an OT environment.

✅Explanation:

The exhibit shows two PLCs connected to the same VLAN (VLAN 1) via a switch, with a firewall also connected to VLAN 1.
Because both PLCs are in the same VLAN and connected through a Layer 2 switch, they can communicate directly without passing through the firewall.
This setup lacks micro-segmentation, which is the practice of enforcing security boundaries even within the same VLAN or subnet.
Without segmentation (e.g., VLAN separation, intra-VLAN firewall inspection, or NAC enforcement), any compromise of one PLC could lead to lateral movement to the other.

❌ Why the Other Options Are Wrong

A. PLCs use IEEE802.1Q protocol to communicate each other Incorrect.
IEEE 802.1Q is used for VLAN tagging, not for PLC-to-PLC communication. PLCs typically use industrial protocols like Modbus, DNP3, or IEC 104.

B. An administrator can create firewall policies in the switch to secure between PLCs Incorrect.
Standard Layer 2 switches do not support firewall policies. Security enforcement must happen at the firewall or via NAC.

C. This integration solution expands VLAN capabilities from Layer 2 to Layer 3 Incorrect.
The topology remains Layer 2. There's no routing or Layer 3 segmentation shown.

📖 Reference
Fortinet NSE7 OT Security Training – Micro-segmentation and intra-VLAN traffic control
ISA/IEC 62443 – Zone and conduit model for OT segmentation

Explanation:
Active authentication in FortiGate OT environments forces users or devices to authenticate before gaining network access (typically in NAC or 802.1X scenarios). FortiGate supports active authentication via its own local user database or by acting as a RADIUS client sending credentials to an external FortiAuthenticator that can enforce two-factor authentication (push, token, etc.).

Correct Option:

A. Two-factor authentication on FortiAuthenticator
FortiAuthenticator is commonly used as an external RADIUS server with FortiGate for active authentication. It supports strong two-factor methods (FortiToken, SMS, email, push) and is the recommended way to enforce MFA during captive portal or 802.1X active authentication in OT deployments.

D. Local authentication on FortiGate
FortiGate can perform active authentication directly using its local user database (captive portal or dot1x). Users are prompted to enter username/password stored locally on the FortiGate, making it a valid and frequently used method when an external server is not deployed.

Incorrect Option:

B. Role-based authentication on FortiNAC
FortiNAC is a separate NAC solution focused on device profiling and passive identification. It does not perform active user authentication for FortiGate; FortiGate cannot use FortiNAC as an authentication server.

C. FSSO authentication on FortiGate
Fortinet Single Sign-On (FSSO) is a passive authentication method that collects logon events from domain controllers or agents. It does not trigger active user challenges, so it cannot be used for active authentication scenarios.

Reference:
FortiOS 7.2 NSE 7 OT Security 7.2 Study Guide – “Active vs Passive Authentication in OT”

Explanation:
Generating a meaningful report in FortiAnalyzer requires the correct dataset. An empty report, despite logs being visible in real-time/historical views, typically indicates a mismatch between the report's query parameters and the available log data. The two most common reasons are selecting a time range where no relevant logs were recorded or choosing device groups or ADOMs that do not contain the logs from the specific firewall(s) generating the traffic.

Correct Options:

B. The administrator selected the wrong time period for the report.
The report is generated based on logs indexed for the specified time period. If the time frame selected (e.g., "Last 1 hour") does not align with when the relevant application traffic was logged, the report query will return empty results, even if logs exist for other times.

C. The administrator selected the wrong devices in the Devices section.
Reports can be filtered to specific devices or device groups. If the administrator runs the report against a subset of devices (or an ADOM) that does not include the actual FortiGate forwarding the application logs, the report will be empty. Logs visible in one ADOM or device view are not automatically included in reports for another.

Incorrect Options:

A. The administrator selected the wrong logs to be indexed in FortiAnalyzer.
While incorrect log indexing settings could cause missing data, the scenario states that "related real-time and historical logs are visible in the FortiAnalyzer." If the logs are visible, they are already being received and indexed correctly, ruling this out as the cause for this specific empty report.

D. The administrator selected the wrong hcache table for the report.
Standard, pre-defined FortiAnalyzer reports like the "Application Risk and Control Report" do not require manual selection of an hcache (historical cache) table. The report engine automatically queries the appropriate internal tables. This is a low-level database concept not typically a user-selectable option in the report interface for such standard reports.

Reference:
FortiAnalyzer Administration Guide on report generation, which emphasizes verifying the Report Time setting and the Device filter within the report configuration. The visibility of logs in log view confirms data is present, making time range and device scope the primary filters to check.