FCSS_ADA_AR-6.7 FCSS Advanced Analytics 6.7 Architect Questions and Answers

The rule triggers an incident when there are two or more VPN logon failures within a 10-minute window, grouped by Source IP, Reporting Device, Reporting IP, and User. Let's analyze the events:

Breakdown of Events:

1. Reporting IP: 1.1.1.1, Source IP: 2.2.2.2, Device: FortiGate, User: Sarah

2. Reporting IP: 1.1.1.1, Source IP: 2.2.2.2, Device: FortiGate, User: John

3. Reporting IP: 1.1.1.3, Source IP: 2.2.2.2, Device: FortiGate2, User: Tom

4. Reporting IP: 1.1.1.3, Source IP: 2.2.2.2, Device: FortiGate2, User: John

5. Reporting IP: 1.1.1.3, Source IP: 2.2.2.2, Device: FortiGate2, User: Sarah

6. Reporting IP: 1.1.1.1, Source IP: 2.2.2.2, Device: FortiGate, User: Tom

Now, applying the grouping criteria (Source IP, Reporting Device, Reporting IP, and User):

● Group 1: (1.1.1.1, 2.2.2.2, FortiGate, John) → 1 occurrence (not enough)

● Group 2: (1.1.1.1, 2.2.2.2, FortiGate, Sarah) → 1 occurrence (not enough)

● Group 3: (1.1.1.1, 2.2.2.2, FortiGate, Tom) → 2 occurrences (incident triggered)

● Group 4: (1.1.1.3, 2.2.2.2, FortiGate2, John) → 2 occurrences (incident triggered)

● Group 5: (1.1.1.3, 2.2.2.2, FortiGate2, Sarah) → 1 occurrence (not enough)

● Group 6: (1.1.1.3, 2.2.2.2, FortiGate2, Tom) → 1 occurrence (not enough)

Final Incident Count:

● One incident for Group 3 (Tom on FortiGate)

● One incident for Group 4 (John on FortiGate2)

FortiSOAR supports multipledata ingestion modesto allow efficient data collection and automation. The three primary modes are:

1.Rule-Based

FortiSOAR ingests data when specific rules are triggered based on defined conditions.

This enables automation and intelligence-driven event ingestion.

2.App Push

External applications canpushdata into FortiSOAR usingAPIs and integrations.

This is useful forreal-time ingestionfrom external tools like SIEMs, ticketing systems, and threat intelligence platforms.

3.Schedule-Based

Data is ingested based onpredefined schedules.

This is useful for periodic polling of external systems, fetching logs, and running automated tasks at set intervals.

FortiSIEM enforces a device limit based on licensing and system-wide constraintsto ensure proper resource allocation and performance management.

The device limit is determined by the purchased license.

● FortiSIEM licensing includes limits on thenumber of devicesthat can be monitored.

● Thelicense type(e.g.,Enterprise vs. Service Provider) defines themaximum number of devicessupported.

For Service Provider editions, the device limit applies system-wide and is shared across all customers.

● In anMSSP (Managed Security Service Provider) setup, the totaldevice limit applies across all customers, rather than being allocated individually.

● This allowsflexible resource allocationbased on customer needs.

When registeringagentsin FortiSIEM, the organization to which they belong depends on how they are installed:

●Windows Agents

● During installation, the setup wizard prompts the user to specify theorganization.

● This ensures the agent is correctly assigned to the organization defined during setup.

●Linux Agents

● Installation on Linux requirescommand-line parameters, including theorganization name.

● This means that the organization is explicitly defined during the installation process.

In a multi-tenant FortiSOAR deployment, a Managed Security Service Provider (MSSP) hosts a shared FortiSOAR instance that serves multiple customers. Each customer operates as a separate tenant within the instance, ensuring data isolation and security.

FortiSOAR uses secure network connectivity (VPNs, direct connections, or secure tunnels) between the MSSP’s FortiSOAR manager node and the customer’s devices.

The customer does not need to install additional software or tenant nodes; instead, the MSSP manages multi-tenancy at the platform level.

When aUser and Entity Behavior Analytics (UEBA) agentisoff-net, meaning it is disconnected from the network and cannot reach the FortiSIEM collector, ittemporarily stores (caches) events locallyuntil it can re-establish a connection.

● This caching mechanismprevents data lossby ensuring events are retained even when the agent is offline.

● Once the connection to theFortiSIEM collector is restored, the agentuploads the cached events.

● This ensurescontinuity in user behavior monitoring, even when users are disconnected.

In FortiSIEM, some incidents may be triggered due to temporary threshold breaches, especially in availability or performance-related monitoring. These temporary anomalies do not necessarily indicate a persistent issue or security threat.

By automatically clearing such incidents, FortiSIEM prevents unnecessary manual intervention and reduces noise in incident management.

In aFortiSIEM deployment,device discoveryis handled by theSupervisor, even when aCollectoris present.

● TheSupervisor initiates active scansusing protocols such asSNMP, WMI, SSH, and API queriesto discover devices in the network.

●Collectors do not perform discovery; they primarilycollect and forward logsfrom designated devices to the Supervisor.

●Workers handle event processing, not discovery.

TheLookupTableGetfunction is designed toenrich event databy referencing a lookup table. However, itcannot be used directly in analytic queriesfor filtering data before processing. Instead, it is meant to be applied as adisplay filterto enhance results after retrieval.

In the given query,LookupTableGet(MalwareIPList : Source IP : Confidence) >= 87is being used in afilter condition, which leads to an error because the function is not valid in this context. It should be appliedafterthe data is retrieved, not as a pre-processing filter.

From the exhibit, the rule exception is set for:

● Time Range: Starts at 00:00:00

● Duration: 2 days

● Recurrence Pattern: December 25th and December 26th

This means that during these two days (every year in December), the rule will not trigger incidents.

Rule exceptions temporarily suppress incident generation during the specified period.

Events are still processed, but no incidents are generated.

Lookup tables and watchlists serve different purposes in Fortinet’s Advanced Analytics:

● Lookup tables allow for structured data storage with multiple columns, making them useful for correlating different attributes or key-value pairs.

● Watchlists are simpler and contain only a single column, often used for quick reference to flagged values, such as IP addresses or user accounts.

From the exhibit, we can determine the IP range that will be added to the CMDB and mapped to Customer E.

● The included IP range is 10.50.0.1 – 10.50.0.50.

● This means any device within this range (10.50.0.1 to 10.50.0.50) will be added to the CMDB.

10.50.0.1 → Falls within the included range (10.50.0.1 – 10.50.0.50) → Added to CMDB.

10.50.0.149 → Falls within the 10.50.0.1 – 10.50.0.50 range → Added to CMDB.

In FortiSIEM, an agent’s status of "Running Inactive" indicates that the agent is installed and running but not actively sending data or has encountered a misconfiguration. The following reasons can cause this status:

1. The agent was registered incorrectly

If an agent was not registered properly, it might not establish a proper connection with the FortiSIEM system, resulting in an inactive status.

2. The agent is temporarily down

If the agent goes offline (e.g., due to system shutdown, network issues, or agent crash), it will show as inactive.

3. The template was not assigned

Agents require a template to function correctly. If no template is assigned, the agent cannot collect or process events, leading to an inactive state.

FortiSIEMcollectorsare responsible forgathering logsfrom devices andforwarding themto the FortiSIEM cluster. Their communication with the cluster follows these key principles:

●Collectors periodically communicate with the supervisor node.

● This allows them toreport status, receive updates, and verify configurations.

●The supervisor periodically checks the health of the collector.

● Thesupervisor monitors the collector’s uptime, connectivity, and performance.

●Collectors upload event data to worker nodes but report health to the supervisor.

●Event logs are uploaded to worker nodesas per theworker upload list, ensuring distributed event processing.

●Health status is always reported directly to the supervisorfor centralized monitoring.