FCSS_ADA_AR-6.7 FortiSIEM Rules and Analytics

FortiSIEM Rules and Analytics Detailed Explanation

This topic focuses on how FortiSIEM uses rules and analytics to monitor logs, detect security incidents, and take action.

Rules Explained

What Are Rules?

• Rules are like "if-this-then-that" instructions used by FortiSIEM.
• They monitor activities and logs to identify suspicious behavior or security incidents.
• When a condition in the rule is met (like a failed login attempt or unusual traffic), an action is triggered, such as sending an alert or blocking an IP.

Structure of Rules

Think of rules as having three main parts:

1. Event Filters:

   • These act like a sieve, filtering out only the logs or events you care about.
   • Example: "Only look at login attempts from IP addresses outside my country."

2. Trigger Conditions:

   • Defines what should happen for the rule to activate.
   • Conditions can be:
     • Time-based: The event happens at unusual hours.
     • IP-based: Events come from a known malicious IP address.
     • Behavioral-based: A user downloads a large number of files suddenly.

3. Action Definition:

   • Specifies what FortiSIEM should do once a rule is triggered.
   • Actions can include:
     • Sending an email to the admin.
     • Isolating a device from the network.
     • Logging the incident for further analysis.

Types of Rules

1. Predefined Rules:

   • These are ready-made rules included in FortiSIEM.
   • Examples:
     • Detecting brute force attacks.
     • Identifying traffic from blacklisted IPs.
   • Best for common security scenarios.

2. Custom Rules:

   • You can create your own rules based on specific requirements.
   • Example: "Alert me if more than 10 login attempts fail from the same IP within 10 minutes."

3. Correlated Rules:

   • These link multiple events together to detect complex attacks.
   • Example: Combining:
     1. A user logging in from a foreign country.
     2. Followed by unusual file downloads.
   • This helps detect sophisticated threats that might not be obvious in a single event.

Analytical Methods

1. Signature-Based Detection

• What It Does:
  Compares logs to a list of known threat signatures, such as:
  • Malicious IPs
  • Malware file hashes
  • Phishing domains
• Example:
  If a log contains traffic to a flagged IP, an alert is triggered.

2. Behavioral Analysis

• What It Does:
  Monitors the usual activity of users and devices to spot anything out of the ordinary.
• Example:
  If an employee who typically accesses 10 files per day suddenly downloads 1000 files, this might indicate suspicious activity.

3. Contextual Correlation

• What It Does:
  Links isolated events together to identify a broader attack pattern.

• Example:
  If:

  1. A user's account is accessed from two countries at the same time (impossible travel).

  2. Followed by multiple failed login attempts.

  • These separate events together suggest an account compromise.

Optimization Tips

1. Reduce False Positives

• False positives are alerts for events that are not real threats.
• To avoid unnecessary noise:
  • Refine rule conditions to make them more precise.
  • Use whitelists to ignore trusted sources (e.g., internal IPs).

2. Test Rules

• Before applying new rules to your live environment:
  • Run them in a test setup to see how they perform.
  • This prevents accidental disruptions caused by overly aggressive rules.

3. Classify Rules

• Assign priority levels to rules based on their importance:
  • High Priority: Events requiring immediate action (e.g., detecting malware).
  • Medium Priority: Suspicious but not urgent (e.g., unusual user behavior).
  • Low Priority: Events for documentation or review (e.g., policy violations).

Simple Analogy for Better Understanding

Think of FortiSIEM Rules as a security guard monitoring a building:

1. Event Filters: The guard checks IDs at the door and only lets in people they need to watch closely.
2. Trigger Conditions: The guard looks for specific behaviors, like someone sneaking into restricted areas.
3. Action Definition: If the guard notices something suspicious, they might sound an alarm, report it, or lock a door.

Summary

1. Rules are the backbone of threat detection, defining what FortiSIEM should monitor and how to respond.
2. Analytics enhance detection by using techniques like:
   • Signature matching for known threats.
   • Behavioral analysis to spot anomalies.
   • Correlation to connect related events.
3. Optimize your rules to:
   • Minimize false positives.
   • Ensure rules align with real-world scenarios.
   • Assign priorities to focus on critical threats first.

FortiSIEM Rules and Analytics (Additional Content)

1. Rule Execution Order in FortiSIEM

How FortiSIEM Prioritizes and Executes Rules

In FortiSIEM, multiple rules can be applied to the same event, so understanding the execution order and priority system is crucial to ensuring the correct rule is triggered first.

• Rule Matching Process

  • When an event is received, FortiSIEM evaluates all active rules against the event data.
  • Each rule has matching criteria (filters, conditions, thresholds), and if an event meets these criteria, the rule gets triggered.

• Priority System for Rule Execution

  • FortiSIEM prioritizes rules based on severity levels:
    • Critical severity rules are executed before high, medium, or low severity rules.
    • Within the same severity level, rules are processed based on their order of creation or modification.
  • Rule Groups and Cascading Rules
    • FortiSIEM allows grouping rules into hierarchical structures.
    • If multiple rules apply to the same event, child rules inherit conditions from parent rules but do not override them unless explicitly defined.

• Handling Rule Conflicts

  • Multiple rules triggering for the same event:
    • FortiSIEM does not stop at the first matching rule; instead, it applies all matching rules sequentially.
    • If two rules contradict each other (e.g., one blocks an action while another allows it), FortiSIEM follows a predefined conflict resolution policy based on severity.
  • Best Practices to Avoid Rule Conflicts:
    • Define mutually exclusive conditions for high-impact rules.
    • Use custom rule prioritization by assigning severity levels.
    • Regularly review conflicting rules and adjust their execution order.

2. False Positives vs. False Negatives in FortiSIEM

False Positives (Incorrectly Flagged Threats)

• Definition: A false positive occurs when a legitimate activity is incorrectly flagged as a security threat.
• Causes:
  • Overly broad detection rules (e.g., flagging all external logins as suspicious).
  • Unoptimized anomaly detection thresholds.

False Negatives (Missed Threats)

• Definition: A false negative happens when a real security threat is not detected.
• Causes:
  • Rules that are too strict: If a rule is overly narrow, some actual threats may not match the defined conditions.
  • Evasion tactics by attackers: Some attacks use low-and-slow techniques to avoid detection.
  • Lack of contextual correlation: If FortiSIEM does not correlate multiple weak signals, an attack might not appear serious enough to trigger an alert.

How to Optimize Rules to Minimize False Positives & False Negatives

• Refine Thresholds Dynamically

  • Use historical data analysis to establish realistic thresholds.
  • Implement adaptive baselines that update based on changing network activity.

• Use Behavioral Analytics (UEBA) for Context-Aware Detection

  • FortiSIEM’s User and Entity Behavior Analytics (UEBA) can learn normal user and system behaviors and flag only significant deviations instead of static thresholds.

• Regular Rule Review and Tuning

  • Periodically review logs and alerts to identify patterns of false positives or false negatives.
  • Test new rules in a controlled environment before deploying them system-wide.

3. Rule Performance Optimization in FortiSIEM

Why Performance Optimization Matters

FortiSIEM processes a high volume of real-time security logs, and inefficient rules can cause:

• Increased system load, leading to slow event processing.
• Excessive false alerts, making it difficult to identify real threats.
• Wasted storage space due to redundant event logging.

Best Practices for Rule Performance Optimization

• Avoid Heavy Computation Rules

  • Limit complex regex-based filters that require high computational power.
    • Example: Instead of using .*@.*\.com, use a more specific condition like domain=xyz.com.
  • Use indexed searches instead of scanning all log data.

• Reduce Redundant Rules

  • Merge similar rules to avoid duplicated alerts.
  • Example:
    • Instead of creating separate rules for different types of login failures, use a single rule with multiple conditions.

• Enable Correlation Instead of Isolated Rule Processing

  • Instead of triggering alerts on single events, correlate multiple conditions before firing an alert.
  • Example:
    • A failed login attempt is normal, but 5 failed logins + a new device + an external IP may indicate an attack.

• Archive Low-Priority Events

  • Not all events require immediate rule execution.
  • Store low-priority logs separately and process them in batch jobs rather than in real time.

4. Enhancing Rule Adaptability in FortiSIEM

Why Rules Should Be Adaptive

• Static rules are often too rigid and may fail to detect evolving attack techniques.
• AI-driven security analytics can help make rules dynamic and self-adjusting.

Methods to Improve Rule Adaptability

1. Auto-Tuning of Thresholds

• Problem: Static thresholds may not account for changing traffic patterns.
• Solution: Use machine learning models to analyze historical data and adjust rule thresholds dynamically.
  • Example:
    • Instead of setting a fixed threshold for login attempts (5 failed logins = alert), FortiSIEM can analyze user behavior over time and detect what is truly abnormal.

2. Using AI to Detect Emerging Attack Patterns

• Problem: Fixed rules only catch known attack patterns but fail against new threats.
• Solution: FortiSIEM can integrate AI-powered threat intelligence:
  • Compare new security logs against previous attack behaviors.
  • Auto-generate new rules based on learned attack vectors.

3. Leveraging Anomaly-Based Detection

• Problem: Attackers can bypass rule-based detection by staying within "normal" behavior limits.
• Solution: Instead of relying solely on predefined rules, FortiSIEM can:
  • Detect anomalies in network traffic, login behavior, and data access patterns.
  • Assign risk scores and trigger rules dynamically only when multiple risk factors align.

4. Integrating Threat Intelligence Feeds

• Problem: Static rule sets do not adapt to new threats (e.g., new malware variants).
• Solution:
  • FortiSIEM can ingest real-time threat intelligence (e.g., FortiGuard threat feeds).
  • Rules can be updated dynamically to block new attack sources as they emerge.

5. Continuous Learning from Incident Responses

• Problem: Security rules are often adjusted manually, leading to delays in improving detection.
• Solution: Implement incident-driven rule improvement:
  • When a new security incident occurs, FortiSIEM can suggest rule adjustments based on:
    • How the attack was detected.
    • What security signals were missed.
  • Security teams can then approve or refine the suggested updates.

Conclusion

1. Rule Execution Order:

• FortiSIEM prioritizes rules by severity and executes multiple matching rules.
• Conflicts are resolved based on predefined priority rules.

2. False Positives vs. False Negatives:

• Reducing false positives requires refining rule thresholds and using behavioral analytics.
• Avoiding false negatives requires correlation-based detection and continuous rule updates.

3. Rule Performance Optimization:

• Avoid complex rules that slow down processing.
• Use event correlation instead of single-event alerts to reduce unnecessary noise.
• Optimize log storage and prioritization for high-performance rule execution.

4. Enhancing Rule Adaptability:

• Implement AI-based rule adjustments.
• Use threat intelligence feeds to dynamically update rules.
• Enable self-learning mechanisms to fine-tune rule conditions based on real incidents.