FCSS_SOC_AN-7-4 Practice Questions

Understanding FortiAnalyzer Roles:

FortiAnalyzer can operate in two primary modes: collector mode and analyzer mode.

Collector Mode: Gathers logs from various devices and forwards them to another FortiAnalyzer

operating in analyzer mode for detailed analysis.

Analyzer Mode: Provides detailed log analysis, reporting, and incident management.

Steps to Configure FortiAnalyzer as a Collector Device:

A . Enable Log Compression:

While enabling log compression can help save storage space, it is not a mandatory step specifically

required for configuring FortiAnalyzer in collector mode.

Not selected as it is optional and not directly related to the collector configuration process.

B . Configure Log Forwarding to a FortiAnalyzer in Analyzer Mode:

Essential for ensuring that logs collected by the collector FortiAnalyzer are sent to the analyzer

FortiAnalyzer for detailed processing.

Selected as it is a critical step in configuring a FortiAnalyzer as a collector device.

Step 1: Access the FortiAnalyzer interface and navigate to log forwarding settings.

Step 2: Configure log forwarding by specifying the IP address and necessary credentials of the

FortiAnalyzer in analyzer mode.

Reference: Fortinet Documentation on Log Forwarding FortiAnalyzer Log Forwarding

C . Configure the Data Policy to Focus on Archiving:

Data policy configuration typically relates to how logs are stored and managed within FortiAnalyzer,

focusing on archiving may not be specifically required for a collector device setup.

Not selected as it is not a necessary step for configuring the collector mode.

D . Configure Fabric Authorization on the Connecting Interface:

Necessary to ensure secure and authenticated communication between FortiAnalyzer devices within

the Security Fabric.

Selected as it is essential for secure integration and communication.

Step 1: Access the FortiAnalyzer interface and navigate to the Fabric authorization settings.

Step 2: Enable Fabric authorization on the interface used for connecting to other Fortinet devices and

FortiAnalyzers.

Reference: Fortinet Documentation on Fabric Authorization FortiAnalyzer Fabric Authorization

Implementation Summary:

Configure log forwarding to ensure logs collected are sent to the analyzer.

Enable Fabric authorization to ensure secure communication and integration within the Security

Fabric.

Conclusion:

Configuring log forwarding and Fabric authorization are key steps in setting up a FortiAnalyzer as a

collector device to ensure proper log collection and forwarding for analysis.

Reference:

Fortinet Documentation on FortiAnalyzer Roles and Configurations FortiAnalyzer Administration

Guide

By configuring log forwarding to a FortiAnalyzer in analyzer mode and enabling Fabric authorization

on the connecting interface, you can ensure proper setup of FortiAnalyzer as a collector device.

Understanding Event Generation in FortiAnalyzer:

FortiAnalyzer generates events based on predefined rules and conditions to help in monitoring and

responding to security incidents.

Analyzing the Options:

Option A: Data selectors filter logs based on specific criteria but do not generate events on their own.

Option B: Connectors facilitate integrations with other systems but do not generate events based on

log matches.

Option C: Event handlers are configured with rules that define the conditions under which events are

generated. When a log matches a rule in an event handler, FortiAnalyzer generates an event.

Option D: Tasks in playbooks execute actions based on predefined workflows but do not directly

generate events based on log matches.

Conclusion:

FortiAnalyzer generates an event when a log matches a rule in an event handler.

Reference:

Fortinet Documentation on Event Handlers and Event Generation in FortiAnalyzer.

Best Practices for Configuring Event Handlers in FortiAnalyzer.

Role of a Threat Hunter:

A threat hunter proactively searches for cyber threats that have evaded traditional security defenses.

This role is crucial in identifying sophisticated and stealthy adversaries that bypass automated

detection systems.

Key Responsibilities:

Proactive Threat Identification:

Threat hunters use advanced tools and techniques to identify hidden threats within the network.

This includes analyzing anomalies, investigating unusual behaviors, and utilizing threat intelligence.

Reference: SANS Institute, "Threat Hunting: Open Season on the Adversary" SANS Threat Hunting

Understanding the Threat Landscape:

They need a deep understanding of the threat landscape, including common and emerging tactics,

techniques, and procedures (TTPs) used by threat actors.

Reference: MITRE ATT&CK Framework MITRE ATT&CK

Advanced Analytical Skills:

Utilizing advanced analytical skills and tools, threat hunters analyze logs, network traffic, and

endpoint data to uncover signs of compromise.

Reference: Cybersecurity and Infrastructure Security Agency (CISA) Threat Hunting Guide CISA Threat

Hunting

Distinguishing from Other Roles:

Investigate and Respond to Incidents (A):

This is typically the role of an Incident Responder who reacts to reported incidents, collects evidence,

and determines the impact.

Reference: NIST Special Publication 800-61, "Computer Security Incident Handling Guide" NIST

Incident Handling

Collect Evidence and Determine Impact (B):

This is often the role of a Digital Forensics Analyst who focuses on evidence collection and impact

assessment post-incident.

Monitor Network Logs (D):

This falls under the responsibilities of a SOC Analyst who monitors logs and alerts for anomalous

behavior and initial detection.

Conclusion:

Threat hunters are essential in a SOC for uncovering sophisticated threats that automated systems

may miss. Their proactive approach is key to enhancing the organization's security posture.

Reference:

SANS Institute, "Threat Hunting: Open Season on the Adversary"

MITRE ATT&CK Framework

CISA Threat Hunting Guide

NIST Special Publication 800-61, "Computer Security Incident Handling Guide"

By searching for hidden threats that elude detection, threat hunters play a crucial role in maintaining

the security and integrity of an organization's network.

Understanding the Event Handler Configuration:

The event handler is set up to detect specific security incidents, such as spearphishing, based on logs

forwarded from other Fortinet products like FortiSandbox.

An event handler includes rules that define the conditions under which an event should be triggered.

Analyzing the Current Configuration:

The current event handler is named "Spearphishing handler" with a rule titled "Spearphishing Rule

1".

The log viewer shows that logs are being forwarded by FortiSandbox but no events are generated by

FortiAnalyzer.

Key Components of Event Handling:

Log Type: Determines which type of logs will trigger the event handler.

Data Selector: Specifies the criteria that logs must meet to trigger an event.

Automation Stitch: Optional actions that can be triggered when an event occurs.

Notifications: Defines how alerts are communicated when an event is detected.

Issue Identification:

Since FortiSandbox logs are correctly forwarded but no event is generated, the issue likely lies in the

data selector configuration or log type matching.

The data selector must be configured to include logs forwarded by FortiSandbox.

Solution:

B . Configure a FortiSandbox data selector and add it to the event handler:

By configuring a data selector specifically for FortiSandbox logs and adding it to the event handler,

FortiAnalyzer can accurately identify and trigger events based on the forwarded logs.

Steps to Implement the Solution:

Step 1: Go to the Event Handler settings in FortiAnalyzer.

Step 2: Add a new data selector that includes criteria matching the logs forwarded by FortiSandbox

(e.g., log subtype, malware detection details).

Step 3: Link this data selector to the existing spearphishing event handler.

Step 4: Save the configuration and test to ensure events are now being generated.

Conclusion:

The correct configuration of a FortiSandbox data selector within the event handler ensures that

FortiAnalyzer can generate events based on relevant logs.

Reference:

Fortinet Documentation on Event Handlers and Data Selectors FortiAnalyzer Event Handlers

Fortinet Knowledge Base for Configuring Data Selectors FortiAnalyzer Data Selectors

By configuring a FortiSandbox data selector and adding it to the event handler, FortiAnalyzer will be

able to accurately generate events based on the appropriate logs.

Understanding the Playbook and its Components:

The exhibit shows a playbook in which an event trigger starts actions upon detecting a malicious file.

The initial tasks in the playbook include CREATE_INCIDENT and GET_EVENTS.

Analysis of Current Tasks:

EVENT_TRIGGER STARTER: This initiates the playbook when a specified event (malicious file

detection) occurs.

CREATE_INCIDENT: This task likely creates a new incident in the incident management system for

tracking and response.

GET_EVENTS: This task retrieves the event details related to the detected malicious file.

Objective of the Next Task:

The next logical step after creating an incident and retrieving event details is to update the incident

with the event data, ensuring all relevant information is attached to the incident record.

This helps SOC analysts by consolidating all pertinent details within the incident record, facilitating

efficient tracking and response.

Evaluating the Options:

Option A: Update Asset and Identity is not directly relevant to attaching event data to the incident.

Option B: Attach Data to Incident sounds plausible but typically, updating an incident involves more

comprehensive changes including status updates, adding comments, and other data modifications.

Option C: Run Report is irrelevant in this context as the goal is to update the incident with event

data.

Option D: Update Incident is the most suitable action for incorporating event data into the existing

incident record.

Conclusion:

The next task in the playbook should be to update the incident with the event data to ensure the

incident reflects all necessary information for further investigation and response.

Reference:

Fortinet Documentation on Playbook Creation and Incident Management.

Best Practices for Automating Incident Response in SOC Operations.

Understanding the Custom Event Handler Configuration:

The event handler is set up to generate events based on specific log data.

The goal is to generate events specifically for spam emails detected by FortiMail.

Analyzing the Issue:

The event handler is currently generating events for both spam emails and clean emails.

This indicates that the rule's filtering criteria are not correctly distinguishing between spam and non-

spam emails.

Evaluating the Options:

Option A: Selecting the "Anti-Spam Log (spam)" in the Log Type field will ensure that only logs

related to spam emails are considered. This is the most straightforward and accurate way to filter for

spam emails.

Option B: Typing type==spam in the Log filter by Text field might help filter the logs, but it is not as

direct and reliable as selecting the correct log type.

Option C: Disabling the rule to use the filter in the data selector to create the event does not address

the issue of filtering for spam logs specifically.

Option D: Selecting "Within a group, the log field Spam Name (snane) has 2 or more unique values"

is not directly relevant to filtering spam logs and could lead to incorrect filtering criteria.

Conclusion:

The correct change to make in the rule is to select "Anti-Spam Log (spam)" in the Log Type field. This

ensures that the event handler only generates events for spam emails.

Reference:

Fortinet Documentation on Event Handlers and Log Types.

Best Practices for Configuring FortiMail Anti-Spam Settings.

Understanding the Playbook and its Components:

The exhibit shows the status of a playbook named "DOS attack" and its associated tasks.

The playbook is designed to execute a series of tasks upon detecting a DoS attack event.

Analysis of Playbook Tasks:

Attach_Data_To_Incident: Task ID placeholder_8fab0102, status is "upstream_failed," meaning it did

not execute properly due to a previous task's failure.

Get Events: Task ID placeholder_fa2a573c, status is "success."

Create SMTP Enumeration incident: Task ID placeholder_3db75c0a, status is "failed."

Reviewing Raw Logs:

The error log shows a ValueError: invalid literal for int() with base 10: '10.200.200.100'.

This error indicates that the task attempted to convert a string (the IP address '10.200.200.100') to an

integer, which is not possible.

Identifying the Source of the Error:

The error occurs in the file "incident_operator.py," specifically in the execute method.

This suggests that the task "Create SMTP Enumeration incident" is the one causing the issue because

it failed to process the data type correctly.

Conclusion:

The failure of the playbook is due to the "Create SMTP Enumeration incident" task receiving a string

value (an IP address) when it expects an integer value. This mismatch in data types leads to the error.

Reference:

Fortinet Documentation on Playbook and Task Configuration.

Python error handling documentation for understanding ValueError.

Understanding the Requirements:

The objective is to create an incident and generate a report based on malicious attachment events

detected by FortiAnalyzer from FortiSandbox analysis.

The endpoint hosts are protected by FortiClient EMS, which is integrated with FortiSandbox. All logs

are sent to FortiAnalyzer.

Key Components:

FortiAnalyzer: Centralized logging and analysis for Fortinet devices.

FortiSandbox: Advanced threat protection system that analyzes suspicious files and URLs.

FortiClient EMS: Endpoint management system that integrates with FortiSandbox for endpoint

protection.

Playbook Analysis:

The playbook in the exhibit consists of three main actions: GET_EVENTS, RUN_REPORT, and

CREATE_INCIDENT.

EVENT_TRIGGER: Starts the playbook when an event occurs.

GET_EVENTS: Fetches relevant events.

RUN_REPORT: Generates a report based on the events.

CREATE_INCIDENT: Creates an incident in the incident management system.

Selecting the Correct Connector:

The correct connector should allow fetching events related to malicious attachments analyzed by

FortiSandbox and facilitate integration with FortiAnalyzer.

Connector Options:

FortiSandbox Connector:

Directly integrates with FortiSandbox to fetch analysis results and events related to malicious

attachments.

Best suited for getting detailed sandbox analysis results.

Selected as it is directly related to the requirement of handling FortiSandbox analysis events.

FortiClient EMS Connector:

Used for managing endpoint security and integrating with endpoint logs.

Not directly related to fetching sandbox analysis events.

Not selected as it is not directly related to the sandbox analysis events.

FortiMail Connector:

Used for email security and handling email-related logs and events.

Not applicable for sandbox analysis events.

Not selected as it does not relate to the sandbox analysis.

Local Connector:

Handles local events within FortiAnalyzer itself.

Might not be specific enough for fetching detailed sandbox analysis results.

Not selected as it may not provide the required integration with FortiSandbox.

Implementation Steps:

Step 1: Ensure FortiSandbox is configured to send analysis results to FortiAnalyzer.

Step 2: Use the FortiSandbox connector in the playbook to fetch events related to malicious

attachments.

Step 3: Configure the GET_EVENTS action to use the FortiSandbox connector.

Step 4: Set up the RUN_REPORT and CREATE_INCIDENT actions based on the fetched events.

Reference:

Fortinet Documentation on FortiSandbox Integration FortiSandbox Integration Guide

Fortinet Documentation on FortiAnalyzer Event Handling FortiAnalyzer Administration Guide

By using the FortiSandbox connector, the analyst can ensure that the playbook accurately fetches

events based on FortiSandbox analysis and generates the required incident and report.

Understanding the Problem:

One FortiGate device is generating a significantly higher volume of logs compared to other devices,

causing the ADOM to exceed its storage quota.

This can lead to performance issues and difficulties in managing logs effectively within FortiAnalyzer.

Possible Solutions:

The goal is to manage the volume of logs and ensure that the ADOM does not exceed its quota, while

still maintaining effective log analysis and monitoring.

Solution A: Increase the Storage Space Quota for the First FortiGate Device:

While increasing the storage space quota might provide a temporary relief, it does not address the

root cause of the issue, which is the excessive log volume.

This solution might not be sustainable in the long term as log volume could continue to grow.

Not selected as it does not provide a long-term, efficient solution.

Solution B: Create a Separate ADOM for the First FortiGate Device and Configure a Different Set of

Storage Policies:

Creating a separate ADOM allows for tailored storage policies and management specifically for the

high-log-volume device.

This can help in distributing the storage load and applying more stringent or customized retention

and storage policies.

Selected as it effectively manages the storage and organization of logs.

Solution C: Reconfigure the First FortiGate Device to Reduce the Number of Logs it Forwards to

FortiAnalyzer:

By adjusting the logging settings on the FortiGate device, you can reduce the volume of logs

forwarded to FortiAnalyzer.

This can include disabling unnecessary logging, reducing the logging level, or filtering out less critical

logs.

Selected as it directly addresses the issue of excessive log volume.

Solution D: Configure Data Selectors to Filter the Data Sent by the First FortiGate Device:

Data selectors can be used to filter the logs sent to FortiAnalyzer, ensuring only relevant logs are

forwarded.

This can help in reducing the volume of logs but might require detailed configuration and regular

updates to ensure critical logs are not missed.

Not selected as it might not be as effective as reconfiguring logging settings directly on the FortiGate

device.

Implementation Steps:

For Solution B:

Step 1: Access FortiAnalyzer and navigate to the ADOM management section.

Step 2: Create a new ADOM for the high-log-volume FortiGate device.

Step 3: Register the FortiGate device to this new ADOM.

Step 4: Configure specific storage policies for the new ADOM to manage log retention and storage.

For Solution C:

Step 1: Access the FortiGate device’s configuration interface.

Step 2: Navigate to the logging settings.

Step 3: Adjust the logging level and disable unnecessary logs.

Step 4: Save the configuration and monitor the log volume sent to FortiAnalyzer.

Reference:

Fortinet Documentation on FortiAnalyzer ADOMs and log management FortiAnalyzer Administration

Guide

Fortinet Knowledge Base on configuring log settings on FortiGate FortiGate Logging Guide

By creating a separate ADOM for the high-log-volume FortiGate device and reconfiguring its logging

settings, you can effectively manage the log volume and ensure the ADOM does not exceed its quota.

Understanding the MITRE ATT&CK Matrix:

The MITRE ATT&CK framework is a knowledge base of adversary tactics and techniques based on

real-world observations.

Each tactic in the matrix represents the "why" of an attack technique, while each technique

represents "how" an adversary achieves a tactic.

Analyzing the Provided Exhibit:

The exhibit shows part of the MITRE ATT&CK Enterprise matrix as displayed on FortiAnalyzer.

The focus is on technique T1071 (Application Layer Protocol), which has subtechniques labeled

T1071.001, T1071.002, T1071.003, and T1071.004.

Each subtechnique specifies a different type of application layer protocol used for Command and

Control (C2):

T1071.001 Web Protocols

T1071.002 File Transfer Protocols

T1071.003 Mail Protocols

T1071.004 DNS

Identifying Key Points:

Subtechniques under T1071: There are four subtechniques listed under the primary technique T1071,

confirming that statement B is true.

Event Handlers for T1071: FortiAnalyzer includes event handlers for monitoring various tactics and

techniques. The presence of event handlers for tactic T1071 suggests active monitoring and alerting

for these specific subtechniques, confirming that statement C is true.

Misconceptions Clarified:

Statement A (four techniques under tactic T1071) is incorrect because T1071 is a single technique

with four subtechniques.

Statement D (15 events associated with the tactic) is misleading. The number 15 refers to the

techniques under the Application Layer Protocol, not directly related to the number of events.

Conclusion:

The accurate interpretation of the exhibit confirms that there are four subtechniques under

technique T1071 and that there are event handlers covering tactic T1071.

Reference:

MITRE ATT&CK Framework documentation.

FortiAnalyzer Event Handling and MITRE ATT&CK Integration guides.