Policy Application

Policy Application Detailed Explanation

1. Policy Types

In Falcon, policies define how the sensor behaves. They control:

What types of threats are blocked or monitored.
What data is collected.
Which user actions are allowed or restricted (e.g., USB use, firewall access).
How and when the sensor updates.

There are four main types of policies in Falcon:

1. Prevention Policy (Endpoint Protection Policy)

This is the core policy that controls:

Real-time protection (against malware, ransomware, fileless attacks).
Detection modes (block or monitor).
Cloud Lookup behavior (query threat intelligence).
IOA (Indicators of Attack) rules enforcement.
Behavioral protections, like PowerShell monitoring.

Key Settings:

Detection mode: Disabled, Detect, or Prevent
Options for each threat category: Malware, Exploit, Ransomware, etc.
Granular rules for file operations, memory usage, scripts, etc.

2. Firewall Policy

This governs host-based firewall settings and integrates with Windows Firewall (on Windows devices).

Key Settings:

Enable/disable Windows Firewall integration.
Define rules for:
- Allowed/blocked applications.
- Ports and protocols.
- Inbound/outbound traffic rules.
Apply settings based on network profile: domain, public, private.

Note: This policy does not replace Windows Firewall—it controls it remotely.

3. Device Control Policy

This controls USB devices and peripherals on endpoints.

Key Use Cases:

Block USB storage (flash drives, external HDDs).
Allow exceptions (e.g., corporate-issued encrypted drives).
Monitor device usage for audit/compliance.

Key Settings:

Block, Allow, or Monitor access by:
- Device class (e.g., USB Mass Storage).
- Specific vendor/device IDs (for granular exceptions).
Option to log all device connection events.

4. Sensor Update Policy

This manages how and when the Falcon sensor updates itself.

Key Settings:

Auto-update on/off.
Allowed update windows (e.g., only update after business hours).
Delay updates on certain groups (e.g., test group vs production).

Best Practice:

Use separate update policies for:

Test systems (get updates early).
Production systems (delay updates slightly after validation).

Summary: Falcon Policy Types

Policy Type	Purpose
Prevention	Core detection/prevention behavior
Firewall	Controls network traffic rules
Device Control	Manages USB and device permissions
Sensor Update	Governs automatic updates of sensors

2. Policy Scopes

In CrowdStrike Falcon, policies are always applied to groups, not directly to individual hosts. This design helps enforce consistency, scalability, and reduces configuration errors in large environments.

1. Policies Are Applied to Groups

What This Means:

Every host must be part of a group to receive a policy.
If a host is not in a group with a policy, it may not be protected properly.

Example:

You have a group called Finance Department. You can assign:

A Prevention Policy for strict detection.
A Device Control Policy to block USB drives.
A Firewall Policy to block risky ports.
A Sensor Update Policy to allow updates only at night.

These policy types are all assigned separately, even though they apply to the same group.

2. Multiple Policy Types per Group

Each group can have one policy of each type assigned:

1 Prevention Policy
1 Firewall Policy
1 Device Control Policy
1 Sensor Update Policy

Example:

Group Name	Prevention Policy	Firewall Policy	Device Control	Sensor Update
`HR Workstations`	HR-Protection-Policy	HR-Firewall-Rules	HR-USB-Block	Default
`Dev Servers`	Dev-Secure	Dev-Firewall-Strict	None	Delay-Updates

If you don’t assign a certain policy type, the hosts in that group will not receive any behavior from that category (e.g., no firewall control).

3. Switching Policy Assignments

You can change the policy assigned to a group at any time.
The update is pushed to all hosts in the group immediately or during the next heartbeat.
This is useful for:
- Testing new policy settings.
- Rolling out stricter rules in stages.
- Responding to incidents (e.g., enabling USB block policy temporarily).

4. Group Precedence

There is no layered or inherited precedence in Falcon. A host receives:

Exactly one policy per type, based on its current group.
There is no merging of policy settings across groups.

Summary:

Concept	Description
Group-based Assignment	Policies apply only to groups.
Multiple Policy Types	Each group can have one of each policy type.
No Inheritance	Each group functions independently.
Dynamic Reassignment	Policies can be swapped out live.

3. Policy Rules and Settings

Each policy type (Prevention, Firewall, Device Control, Sensor Update) includes configurable rules and settings toggles that define how Falcon behaves on the endpoint.

1. Prevention Policy Settings

This is the most detailed policy. It controls the core of Falcon’s threat prevention capabilities.

Key Sections:

Malware Protection
- Real-time protection toggle (on/off)
- Detection mode: Detect Only or Prevent
- Machine Learning levels: Aggressive, Moderate, Cautious
Exploit Prevention
- Protects against memory-based attacks (e.g., buffer overflows)
- Script protection: PowerShell, WScript, JavaScript blocking
IOA (Indicator of Attack) Rules
- Custom or default logic-based rules to detect suspicious behavior
- Example: Detect Office apps spawning cmd.exe
Cloud Lookup
- Sends file hashes and metadata to Falcon Cloud for live intelligence
Sensor Behavior Settings
- Controls logging, quarantine behavior, scan throttling

2. Firewall Policy Settings

This policy enables centralized control of host-based firewalls (mainly on Windows).

Key Sections:

Enable/Disable firewall integration
Network Profile-specific rules:
- Domain, Private, Public profiles
Rule Types:
- Allow/block by application path
- Allow/block by port or IP range
Direction:
- Control inbound, outbound, or both
Protocol-specific controls (e.g., TCP, UDP, ICMP)

Example Rule:

Block all outbound traffic from unknown applications on Public networks.

3. Device Control Policy Settings

Designed to manage USB and external device access.

Key Sections:

Device Access Control:
- Block or monitor external storage devices
Granular Rules:
- Allow or deny by:
  - Vendor ID (VID)
  - Product ID (PID)
  - Serial Number
Logging Settings:
- Track device connection/disconnection
- Alert on unapproved device usage

Example:

Allow only corporate-issued encrypted USB drives; block everything else.

4. Sensor Update Policy Settings

Manages when and how the Falcon sensor updates on endpoints.

Key Sections:

Auto-Update Toggle (on/off)
Update Window:
- Set specific days/times when updates are allowed
- Example: Only update between 1 AM – 4 AM, Monday to Friday
Sensor Version Controls (for advanced scenarios):
- Delay rollout to groups until tested
- Manually push versions to test groups

Additional Details:

Some settings are simple toggles (on/off).
Others use JSON-based configuration, especially for IOA rules or firewall advanced rules.
Changes take effect as soon as hosts sync with the cloud (typically within a few minutes).

Best Practices:

Task	Best Practice
Malware Detection	Set to "Prevent" for production systems
Firewall Control	Use test groups to validate rules
USB Management	Use audit mode (monitor) before enforcing block
Policy Testing	Clone existing policy → make edits → assign to small group

4. Inheritance and Precedence

Unlike some endpoint protection platforms that use layered policies with inherited settings, CrowdStrike Falcon follows a flat policy model. This design avoids complexity and makes behavior more predictable—but it also comes with certain trade-offs.

1. No Inheritance Model

In Falcon:

Policies are not layered or nested.
There’s no “parent policy” or “base template” that others inherit from.
Each group is assigned a full policy of each type (Prevention, Firewall, etc.).
That policy stands alone—there’s no cumulative effect from other policies.

What this means:

You must fully define each policy.
If you want multiple groups to share a common setting (e.g., USB blocking), you must replicate that setting in each relevant policy.

2. No Precedence Rules Between Groups

Each host belongs to only one group, and that group entirely controls:

Which policy it gets.
What rules are enforced.

There is no fallback or override based on other group memberships.

A host cannot “partially” inherit settings from another group or policy.

3. Policy Assignment Is Direct and Exclusive

Here’s what happens under the hood:

Host joins group → Group has policy assigned → Policy applies 100%
If the host changes groups, it instantly adopts the new group’s policy.
This makes policy switching easy, but means you must manage group membership carefully.

4. Benefits of the Flat Model

Benefit	Description
Simplicity	No merging conflicts or inheritance chains
Predictability	Hosts always run exactly one policy per type
Speed	Less logic to evaluate means faster policy resolution
Transparency	Easy to audit which policy a host is using

5. Challenges of the Flat Model

Limitation	How to Address It
No layered enforcement	Use tags + dynamic groups to simulate context
Manual duplication of shared settings	Use policy cloning (see next part)
No exceptions per-host	Apply local overrides via host settings when needed

Real-World Example:

You have:

A base policy for most employees
A stricter policy for executives

Instead of layering a "base + executive" policy, you must:

Create two separate full policies: one for All Staff, another for Executive Devices.
Assign each group their respective complete policy set.

5. Versioning and Cloning

In Falcon, policies are frequently updated to adapt to:

New threats or security requirements.
Operational feedback (e.g., false positives).
Business changes (e.g., new device types or workflows).

To avoid mistakes and maintain reliability, Falcon supports policy cloning and versioning—a best practice for secure change management.

1. Cloning Policies

What Is Cloning?

Cloning creates an exact copy of an existing policy. You can edit the clone without affecting the original.

Why Clone?

To test new settings before rolling them out.
To create a specialized version for a subset of hosts.
To update policy content without impacting production machines.

How to Clone a Policy:

Go to Configuration → Policies.
Find the policy you want to copy.
Click “Clone” or “Duplicate”.
Name your new policy (e.g., “Prevention-Strict-v2-Test”).
Make your edits and save.

Note: The cloned policy is not active until it’s assigned to a group.

2. Versioning Policies

Falcon does not track version numbers automatically, so you need to manage versions through naming.

Best Practice: Use Descriptive Names

Include:

Policy function (Prevention, Firewall, etc.)
Risk level or audience (Strict, Standard, Developers)
Version or date (v1.3, 2025-07, etc.)

Example: Prevention-Finance-Strict-v1.2

This helps:

Track changes across environments.
Communicate policy versions in documentation or during incidents.
Revert safely if something breaks.

3. Policy Testing Workflow

A safe policy rollout strategy often looks like this:

Phase	Group	Purpose
Test	Small IT/dev team	Evaluate new settings
Pilot	Selected departments	Watch real-world effects
Production	All applicable hosts	Full enforcement

You move hosts between groups or assign the policy to more groups as confidence grows.

4. Reverting to a Previous Version

If something goes wrong with a new policy:

Simply reassign the group to the older, stable policy.
You don’t need to undo changes—just swap policy assignments in the group configuration.

5. Audit and Change Control

Document who created or changed policies (track via audit logs).
Use policy descriptions in the console to explain purpose or changes.
Set internal review dates to reevaluate policies regularly.

Summary:

Practice	Benefit
Clone before editing	Protects live systems
Use clear naming	Aids tracking and rollback
Test in small groups	Reduces risk of mass disruption
Document changes	Supports audit and troubleshooting