CCFA-200 Group Creation

Group Creation Detailed Explanation

1. Static Groups and Dynamic Groups

CrowdStrike Falcon uses groups to organize and manage hosts more efficiently. Groups are key for applying the right policies, generating focused dashboards, and managing alerts based on host characteristics.

1. Static Groups

What Are Static Groups?

Static groups are manually managed collections of hosts. You choose exactly which hosts go into each group.

How to Create a Static Group:

1. Go to “Host Setup and Management → Groups”.

2. Click “Create Group”.

3. Enter a name (e.g., “Finance Dept”).

4. Choose “Static” as the group type.

5. Manually select hosts to add to the group.

Pros of Static Groups:

• Simple to understand and manage.

• Useful for fixed teams or departments that rarely change (e.g., Accounting, HR).

Limitations:

• Must be updated manually when hosts change.

• Easy to forget to assign new hosts.

2. Dynamic Groups

What Are Dynamic Groups?

Dynamic groups are automatically populated based on rules and filters. You define conditions (like OS type, hostname, or tags), and Falcon adds matching hosts.

How to Create a Dynamic Group:

1. Same as above: Host Setup → Groups → Create Group.

2. Choose “Dynamic” as the group type.

3. Define membership rules using logic filters.

Example Rule:

Operating System = Windows 10
AND
Tag contains Location:NYC

Any host that matches these criteria will automatically join the group. When a host no longer matches the criteria, it’s removed.

Pros of Dynamic Groups:

• No manual updates needed.

• Always current and accurate.

• Ideal for cloud environments, VDI, or large organizations.

Limitations:

• Requires good tagging and hostname conventions.

• Slightly more complex to configure than static groups.

Real-World Comparison:

Feature	Static Group	Dynamic Group
Membership	Manual	Automatic (based on rules)
Best Use	Small, fixed environments	Large, fast-changing environments
Setup Effort	Low	Medium (depends on filters/tags)
Maintenance	Manual updates	Self-updating

2. Group Membership Logic

When you create dynamic groups, Falcon uses filters and conditions to automatically assign hosts. This logic is built similarly to search filters—but instead of just finding hosts, it defines group membership.

1. Basic Rule Components

Each dynamic group rule is made of conditions based on host attributes, such as:

Attribute	Example Values
Hostname	starts with "WIN-"
OS	Windows 10, macOS Ventura
Tags	Dept: Finance, Location: APAC
Sensor Version	7.03.14702.0
Group Name	"DevOps Machines"

2. Logical Operators

You can combine multiple conditions using:

• AND – all conditions must be true.

• OR – at least one condition must be true.

• NOT – excludes hosts that meet a condition.

Examples:

Example 1:

Operating System = Windows 10
AND
Tag contains Dept:HR

→ Matches only Windows 10 hosts tagged as HR.

Example 2:

Tag contains Location:NYC
OR
Tag contains Location:London

→ Matches hosts from either location.

Example 3:

NOT (Sensor Version < 7.0)

→ Excludes outdated sensors.

3. Matching Rules in Practice

Falcon evaluates each host continuously:

• When a host changes (e.g., new tag, different OS), Falcon re-evaluates it against your group logic.

• If the host now matches, it is automatically added to the group.

• If the host no longer matches, it is removed.

4. Group Membership Visibility

To check why a host is or isn’t in a group:

1. Go to the host’s detail page.

2. Look at its group memberships.

3. Review tags and properties to troubleshoot mismatches.

Best Practices for Membership Logic:

• Keep rules simple and focused (avoid too many nested conditions).

• Use consistent tags across all hosts (e.g., Dept:IT, not ITDept, IT, and InfoTech).

• Test your logic using the same filters in the Host view before applying it to a group.

• Regularly review your dynamic groups to ensure they still match your org structure.

3. Group Hierarchies

1. Falcon’s Group Architecture: Flat, Not Nested

CrowdStrike Falcon uses a flat group structure, meaning:

• No nested groups (you cannot place one group inside another).

• Each host can belong to only one group at a time.

• Group priority is not a factor—only direct membership matters.

This design keeps group logic simple and fast, especially in large environments, but it limits some forms of hierarchical control.

2. How to Simulate Hierarchical Behavior

Although true nesting isn’t supported, you can simulate hierarchy using:

A. Naming Conventions

Use consistent prefixes/suffixes to organize by function or department.

• Example:

  • Corp::IT

  • Corp::IT::Windows

  • Corp::IT::macOS

This makes the group list easier to navigate.

B. Tags + Dynamic Filters

Use tags to reflect multi-layered attributes and build dynamic groups accordingly.

• Example tags:

  • Dept:IT

  • OS:Windows

  • Region:APAC

Then define a dynamic group as:

Tag contains Dept:IT
AND
Tag contains OS:Windows

This lets you combine traits without nesting groups.

C. Policy Duplication for Subgroups

If you want different policies for “subgroups” (e.g., IT::HR vs IT::Finance), create separate groups and policies, even if they share similar base settings.

3. Why Falcon Uses Flat Grouping

• Simpler policy assignment and logic.

• Faster host evaluation and group updates.

• Avoids complexity in large-scale environments.

• Encourages use of tagging and filters for structure.

4. Common Pitfalls to Avoid

• Trying to build nested logic inside group names only—remember, naming helps you visually, but Falcon doesn’t treat them as parents/children.

• Overusing groups instead of tags—groups are for policy enforcement, tags are better for labeling and searching.

Recap:

Feature	Falcon Supports?	Notes
Nested groups	No	Use tags instead
One host in many groups	No	One group only
Dynamic filters by tag	Yes	Preferred method
Simulated hierarchy	Via naming/tags	Good for structure

4. Use Cases

Groups are more than just a way to organize hosts. In Falcon, they are essential for policy enforcement, visual reporting, and focused incident response.

1. Policy Targeting

This is the most important use case for groups.

How it works:

• Policies in Falcon are applied to groups, not individual hosts.

• When a host joins a group, it automatically receives the policy linked to that group.

Examples:

• Group: Finance Workstations → Policy: “High Detection Sensitivity”

• Group: Developer Laptops → Policy: “Lower IOA strictness”

• Group: Data Center Servers → Policy: “Firewall + Device Control Enabled”

Use dynamic groups for auto-scaling environments, so hosts always get the right protection without manual updates.

2. Dashboard Segmentation

Groups can be used to filter data in dashboards. This helps stakeholders focus on relevant information.

Examples:

• Security team builds a dashboard for:

  • Group = Corporate Workstations → View only detections for office users.

• Infrastructure team builds:

  • Group = Prod Servers → Focus on uptime, health, and sensor versions.

Benefits:

• Better visibility.

• Customized views for different departments.

3. Alert Management and Response Prioritization

Security teams may want to treat alerts differently based on group.

Use Cases:

• Tag alerts from Executive Devices with higher severity.

• Auto-notify IR team for detections in Critical Assets group.

• Set up automated Fusion workflows triggered by group membership (e.g., auto-containment for High-Risk Systems).

4. Reporting and Audit

Groups let you create precise, segmented reports based on:

• Department

• Location

• OS

• Role

You can:

• Export host inventory by group.

• Generate compliance reports (e.g., “All hosts in PCI Group have latest sensor”).

5. Operational Segmentation

Use groups to divide infrastructure for IT operations:

• Patching groups (e.g., “Wave 1 Servers”)

• Legacy systems group (e.g., “Win7 Machines”)

• External contractor laptops group

This helps in:

• Tracking unsupported systems.

• Applying lighter or stricter controls.

Summary:

Use Case	Purpose
Policy Application	Ensures hosts get the right settings
Dashboard Filtering	Focused visibility
Response Targeting	Priority incident response
Compliance Audits	Proof of protection and policy coverage
Operational Management	Lifecycle and legacy system control

Group Creation (Additional Content)

Designing a minimal-but-powerful host group taxonomy (so policy targeting stays predictable)

Why this matters

Most “policy is wrong” problems are actually group design problems: too many groups, unstable membership rules, or undocumented overlaps. The exam tends to reward answers that create predictable targeting with a small number of well-defined groups.

A practical taxonomy that scales (3 axes, not 300 groups)

Build groups around stable operational boundaries:

• Environment: Dev/Test, Staging, Production

• Criticality: Standard, High-Critical (tier-0 / crown jewels)

• Workload type: Workstations, Servers, Special platforms (VDI, jump hosts)

Rule of thumb: if a group doesn’t change how you operate (policy, rollout ring, reporting, ownership), it’s probably unnecessary.

Membership stability: choose criteria that won’t “drift”

Prefer membership rules that remain stable over time:

• Stable: ownership tags, environment labels, server/workstation classification, site codes that don’t change weekly

• Risky: DHCP IP-only membership, temporary naming patterns, ad-hoc “contains this substring” rules without a naming standard

When you must use unstable fields (like IP ranges), add a second stabilizer (tag/label/site) to prevent accidental drift.

Exam relevance & common traps

• Trap pattern: “Create a separate group for every exception.” Better answers show few groups + strong governance.

• Trap pattern: “Use IP only.” Better answers mention stable identifiers + two-key confirmation.