CCFA-200 Rule Configuration

Rule Configuration Detailed Explanation

1. Custom IOA Rules

What Are IOA Rules?

IOA stands for Indicator of Attack. Unlike IOCs (which flag known threats), IOAs are designed to identify suspicious behaviors that might indicate an attack—even if the file or command is not yet recognized as malicious.

Custom IOA rules allow you to write your own behavioral detections using Falcon’s internal DSL (Domain-Specific Language).

Why Create Custom IOA Rules?

• Detect unique threats that aren’t covered by default protections.

• Add business-specific protections (e.g., block certain scripts in finance).

• Enforce internal security policies (e.g., block running curl from PowerShell).

How Are IOA Rules Written?

They follow a logic-based syntax using:

• Conditions (e.g., command_line contains "Base64").

• Processes (e.g., parent_process_name = powershell.exe).

• Actions (e.g., block, alert, or both).

Example Rule:

Detect PowerShell using Base64 encoding (often used in obfuscated attacks):

process_name = "powershell.exe" AND command_line contains "Base64"

This would trigger if a process matches both conditions.

IOA Rule Targets

You can apply rules to specific:

• Groups – using the same logic as dynamic host groups.

• OS types – e.g., only apply a rule to Windows or Linux machines.

Actions IOA Rules Can Trigger:

Action Type	Description
Alert Only	Creates a detection, but allows the action to continue
Prevent	Blocks the behavior from completing
Alert + Prevent	Both alerts and blocks the action

How to Create a Custom IOA Rule (Step-by-Step)

1. Go to Configuration → Custom IOA Rules.

2. Click “Create Rule”.

3. Choose:

   • Platform (Windows/macOS/Linux)

   • Rule Scope (group or global)

4. Write the rule logic using DSL syntax.

5. Set the Action (Alert, Prevent, or both).

6. Name and describe the rule (add comments for internal context).

7. Optionally assign tags or expiration dates.

8. Save and Deploy the rule to a test group first.

Best Practices:

Tip	Why It Matters
Start in alert-only mode	Prevents accidental disruptions
Test with small group	Minimizes business impact
Document each rule	Helps during audits and tuning
Avoid overly broad logic	Reduces false positives

2. Indicators of Compromise (IOCs)

What Are IOCs?

IOCs, or Indicators of Compromise, are known threat artifacts that security teams use to identify infections or malicious activity. These include:

• File hashes (e.g., SHA256)

• IP addresses

• Domains or URLs

When Falcon sees any of these on an endpoint or in network traffic, it can:

• Alert you

• Block the connection or process

• Trigger a custom workflow

Why Use IOCs in Falcon?

• Respond faster to threat intelligence (e.g., new malware hash from your SOC).

• Block known-bad IPs/domains associated with phishing or malware.

• Extend Falcon detection using your own or third-party intel feeds.

How to Upload IOCs

1. Navigate to IOC Management in the Falcon Console:

   • Configuration → Custom IOCs or Indicators tab.

2. Click “Upload IOC”.

3. Fill out:

   • IOC Type (Hash, IP, Domain, etc.)

   • Value (the actual hash or domain)

   • Action (Alert, Prevent, or Both)

   • Expiration Date (optional)

   • Tags or Descriptions (for tracking or auto-assignment)

Batch Upload Option:

• You can upload multiple IOCs using a CSV or JSON file.

IOC Lifecycle

Each IOC can have:

• Start and End dates

• Optional auto-expiry

• Tags (e.g., “APT29”, “Finance-Only”)

• Group targeting (apply to only certain device groups)

This lets you automatically retire outdated intelligence or control where IOCs apply.

IOC Matching in Falcon

Falcon sensors match IOCs in real time against:

• File system access (hashes)

• Network connections (IPs and domains)

• Process activity (command lines, file loads)

When a match is found, Falcon triggers:

• A detection alert

• A preventive action (if configured)

Best Practices for Using IOCs

Practice	Reason
Use tags to track source or campaign	Helps during investigations
Set expirations for time-sensitive intel	Keeps database clean
Test in alert-only mode first	Prevents false positives
Regularly review IOC hit data	Helps tune detection effectiveness

Real-World Scenario:

Your threat intel team receives indicators of a phishing campaign:

• SHA256 hash of payload

• 2 known malicious IPs

• 1 fake login domain

You:

1. Upload them as IOCs with Prevent action.

2. Assign them to your High-Risk Targets group.

3. Set auto-expiry for 30 days.

4. Monitor detection hits daily.

3. Detection Suppression

What Is Detection Suppression?

Detection Suppression allows you to intentionally suppress (hide) specific detection events from appearing in the Falcon console. This is useful for:

• Known false positives

• Legitimate activity that’s flagged repeatedly

• Custom internal applications triggering alerts

Suppression does not stop the sensor from detecting the event—it simply prevents the alert from surfacing.

Why Use It?

• Reduce alert fatigue for analysts.

• Focus on true threats, not noise.

• Avoid unnecessary escalations for benign but suspicious behavior.

How to Suppress a Detection

There are three main ways to suppress detections:

1. From the Detection Console:

• Go to Activity → Detections.

• Open the detection you want to suppress.

• Click “Create Suppression Rule”.

• Choose your suppression criteria (see below).

2. From the Configuration Menu:

• Go to Configuration → Detection Suppression Rules.

• Click “Create Rule” and define the conditions manually.

Suppression Criteria Options

You can suppress detections based on:

Criterion	Example
Detection ID	Suppress one specific incident
SHA256 Hash	Ignore future detections for a known file
Process Name	Suppress actions by trusted internal tools
Command Line Pattern	Ignore known scripts that trigger alerts
File Path	Exclude a specific folder or directory

You can combine multiple conditions for tighter control.

Suppression Scope

• Suppression can be global or group-specific.

• You can apply suppression to:

  • All hosts

  • Only hosts in a specific group

Example:

Suppress alerts from a custom finance tool only on Finance Dept machines.

Best Practices

Practice	Benefit
Document each suppression	Prevents misconfiguration or abuse
Time-limit suppression rules	Forces periodic review (e.g., expire in 30 days)
Use tags on suppression rules	Helps organize and track purpose
Avoid suppressing critical detections	Confirm root cause before suppressing anything

Real-World Example:

You have a homegrown script called cleanup_temp.bat that runs every night and triggers Falcon’s behavioral alerts.

You:

1. Open the detection for the script.

2. Create a suppression rule for:

   • command_line contains "cleanup_temp.bat"

   • Target group: IT Automation

3. Set the suppression to expire in 60 days.

4. Log the rationale in the rule description.

4. Whitelist and Blacklist Management

What Is It?

• The whitelist (also called "allow list") tells Falcon to ignore or permit specific known files or applications—even if they look suspicious.

• The blacklist (also called "block list") tells Falcon to automatically block or alert on specific files, regardless of normal behavior or AI scores.

These are typically managed within the Prevention Policy under Hash Control Settings.

1. Whitelisting Files (Allow List)

Used to avoid false positives or prevent legitimate tools from being blocked.

How to Add a File to the Allow List:

1. Go to Configuration → Prevention Policies.

2. Edit the relevant policy and navigate to the "Hash Control" section.

3. Add a SHA256 hash of the file you want to allow.

4. Set the action to “Allow”.

When to Use:

• Internal tools (e.g., legacy in-house software).

• Automation scripts known to trigger false detections.

• Software flagged by ML but verified as safe.

Be cautious—allowing a file disables ALL detection/prevention for that file across its group.

2. Blacklisting Files (Block List)

Used to proactively block known malicious files or prevent risky tools from executing.

How to Add to the Block List:

1. Follow the same steps as for the allow list.

2. Add the file’s hash and set action to “Block”.

3. Optionally provide:

   • Description (e.g., “Known ransomware variant”)

   • Expiry date (if threat is temporary)

   • Tags for organizing entries

Common Use Cases:

• Blocking known malware not yet detected by Falcon ML/IOA.

• Preemptively denying risky remote administration tools.

• Quarantining leaked or stolen tools (e.g., Mimikatz).

3. Tips for Using Hash Lists

Tip	Reason
Always validate file hash before whitelisting	Avoid permitting disguised malware
Use a test group to trial new entries	Prevent mass rollout of mistakes
Document reason for adding/removing each hash	Helps with audits and response
Review and expire old entries regularly	Keeps the list accurate and lean

4. Combining with IOA and IOC Rules

You can combine:

• IOA Rules → Behavioral detection

• IOC Entries → External threat feeds

• Hash Control Lists → Precise enforcement

Together, these tools offer multi-layered defense:

• Behavior (IOA) catches unknown threats.

• IOC/Hash lists catch known ones quickly.

Real-World Example:

Your red team uses a tool called payload.exe for internal testing. It keeps getting blocked.

You:

1. Add its SHA256 hash to the allow list for the Red Team group.

2. Exclude it from detection, only in test environments.

3. Add an expiry date for 7 days.

4. Monitor usage to ensure no abuse.

5. Testing and Validation

Why Test and Validate Rules?

CrowdStrike Falcon’s rule engine is powerful, but improper configuration can lead to:

• False positives (interrupting legitimate operations)

• False negatives (failing to detect actual threats)

• Overblocking, which could impact productivity

Testing helps you:

• Confirm your logic is sound

• Minimize operational risk

• Build stakeholder confidence before rollout

1. Create a Test Group

Before applying a new rule widely:

• Set up a dedicated test host group (e.g., Policy Test Devices)

• Assign it:

  • A test policy (clone of production, with new rules added)

  • Access to representative endpoints (e.g., Windows, macOS, servers)

Why Use a Test Group?

• Prevents mistakes from affecting production systems.

• Lets you observe real-world behavior.

2. Use Alert-Only Mode First

For:

• Custom IOA rules

• IOC entries

• Hash lists (optional)

Set the action to:

• “Detect” or “Alert Only”, NOT “Prevent”

This lets you observe:

• What would have been blocked

• Whether the match criteria is too broad or too narrow

3. Simulate Rule Matches

For IOA rules, test with controlled activity such as:

• Running a PowerShell script with a Base64 string

• Executing a fake malware dropper with a known hash

• Creating test files/domains to trigger IOC rules

Ensure simulation does not violate company policies or trigger unnecessary escalations.

4. Monitor Detection Console

Go to Activity → Detections and filter by:

• Source = Custom IOA

• IOC Match = True

• Target Group = Your Test Group

Look for:

• Expected detections

• Unexpected or excessive matches

• Host behavior and performance impact

5. Adjust and Re-Test

Based on your test results:

• Refine rule conditions (e.g., use starts with instead of contains)

• Add exclusions for known good apps

• Document what changed and why

Repeat this cycle until:

• You achieve high accuracy

• No critical disruptions are observed

6. Roll Out Gradually

Once validated:

1. Roll out to a pilot group (e.g., 10–20% of production)

2. Continue monitoring

3. Expand to full deployment

Summary: Testing and Validation Workflow

Step	Action
1	Clone policy, assign to test group
2	Set rules to alert-only
3	Simulate and monitor
4	Tune and iterate
5	Pilot in real groups
6	Finalize production rollout