Shopping cart

Subtotal:

$0.00

CCFA-200 Host Management and Setup

Host Management and Setup

Detailed list of CCFA-200 knowledge points

Host Management and Setup Detailed Explanation

1. Host Inventory

What is Host Inventory?
Host Inventory is the central list of all endpoints that have the Falcon sensor installed and are reporting back to the Falcon Cloud. It’s where you can see and manage every protected device in your environment.

Where to Find the Host Inventory

  1. Log in to the Falcon Console.

  2. Navigate to “Host Management” → “Hosts”.

This screen shows a table of all active and inactive hosts, including details about their configuration, health, and activity.

Key Columns and What They Mean

Column Name Description
Hostname The device name reported by the OS.
OS Type Windows, macOS, Linux – includes version.
Group Membership The host’s assigned Falcon group (used for policies).
Sensor Version The exact version of the installed sensor.
Last Seen Timestamp of last communication with Falcon Cloud.
Policy Applied The policy bundle currently applied to the sensor.
Status Whether the host is Online, Offline, or Contained.

What You Can Do from the Host Inventory Page

  • Click a hostname to open a detailed view, including:

    • Detection history

    • Sensor install logs

    • Assigned policies

  • Launch actions (e.g., contain, RTR, or update sensor) from here.

  • Export host lists to CSV format for reports or audits.

Example Use Case

You want to confirm whether all machines in your Finance department have the latest sensor installed:

  • Use filters (see next part) to narrow to the Finance group.

  • Check the Sensor Version column.

  • Click into hosts with outdated versions and plan updates.

2. Filters and Tagging

When you're managing dozens, hundreds, or even thousands of endpoints in Falcon, you need a way to quickly find, group, and manage specific hosts. That’s where filters and tags come in.

1. Filters: Narrowing Down Hosts

The filtering system in Falcon is very powerful and flexible.

Common Filter Options:
  • Hostname (e.g., starts with "WIN-")

  • OS Type/Version (e.g., Windows 10, macOS 13)

  • Group Name

  • Sensor Version

  • Online/Offline Status

  • Policy Name

  • Tag Value

  • Containment Status

How to Use Filters:
  1. Go to Host Management → Hosts.

  2. Click “Add Filter”.

  3. Choose a category (e.g., "Policy Applied").

  4. Choose an operator (e.g., "equals", "contains").

  5. Enter a value (e.g., "Windows Policy Set").

You can add multiple filters together to create complex searches.

2. Tags: Custom Metadata for Hosts

Tags are custom labels you can assign to hosts. They're extremely useful for:

  • Categorizing machines by department, location, or usage.

  • Grouping machines that share the same risk level.

  • Linking devices to projects, tickets, or external systems.

Examples of Tags:
  • Department: Finance

  • Location: Tokyo

  • Role: WebServer

  • Owner: John.Smith

How to Assign Tags:
  1. Select one or more hosts in the host list.

  2. Click “Actions → Add Tag”.

  3. Choose existing tags or create a new one.

  4. Tags will now be visible in the host list and searchable via filters.

Best Practices for Filters and Tags

  • Use a consistent naming convention (e.g., Dept:HR, Dept:IT).

  • Review and clean up unused or outdated tags regularly.

  • Use filters to create custom dashboards that track specific segments of your environment.

Real-World Scenario:

You’re planning a phased rollout of a new policy and want to apply it only to servers in New York.

Steps:

  1. Use a filter: Tag contains Location:NYC.

  2. Review the list and verify roles.

  3. Apply the new policy only to that filtered group.

3. Host Status Indicators

Falcon provides visual indicators and status information for each host. These statuses help you understand at a glance whether a machine is:

  • Properly connected

  • Running a healthy sensor

  • Protected by the correct policies

1. Online vs. Offline Status

  • Online:
    The host has recently communicated with the Falcon Cloud.

    • Seen in the “Last Seen” column (e.g., “5 minutes ago”).
  • Offline:
    The sensor has not communicated in a while (e.g., 7+ days).

    • Could mean the device is shut down, off-network, or sensor is misconfigured.
Tips:
  • Use filters like Last Seen > 7 days ago to find stale/inactive hosts.

  • Offline does not always mean broken—could just be a laptop that’s turned off.

2. Sensor Health Indicators

These show whether the sensor is:

  • Installed and functioning correctly.

  • Communicating with Falcon Cloud.

  • Updating properly.

Common Indicators:
  • Green: Healthy and connected.

  • Yellow: Warning – sensor may be outdated or partially connected.

  • Red: Error – no communication, invalid CID, or other issue.

How to View:

Click a host → look at the Sensor Health section in the details panel.

3. Policy Status

This tells you:

  • Whether a policy is applied.

  • Which policy is assigned (by name).

  • If any errors occurred during policy application.

Key Statuses:
  • Policy Applied (shows the name)

  • Missing Policy – happens if the host group doesn’t have one assigned.

  • Policy Error – policy failed to load due to conflict or version mismatch.

4. Containment Status

Indicates whether the host is isolated from the network (except to Falcon Cloud).

  • Contained: Host has been placed in quarantine.

  • Not Contained: Normal state.

Containment is used in incident response to stop potential threats from spreading.

5. Tamper Protection

Shows whether the sensor has tamper protection enabled, which prevents unauthorized uninstallation or modification.

  • Enabled: Sensor cannot be removed without a maintenance token.

  • Disabled: Sensor could be uninstalled by local admin.

Real-World Use Case:

Your SOC analyst sees a host that triggered a critical detection. You:

  1. Go to the Host Inventory.

  2. Filter for that hostname.

  3. See that it’s online, but sensor health = yellow and policy missing.

  4. Investigate further—maybe the machine isn’t in the right group.

4. Host Actions

These are powerful administrative functions that let you take direct action on a host from the Falcon UI. They’re essential for incident response, sensor troubleshooting, and host maintenance.

1. Real Time Response (RTR)

What is RTR?

RTR is a secure command-line shell that gives security analysts and administrators remote access to an endpoint.

Key Capabilities:
  • Run investigative commands (e.g., view files, check registry keys).

  • Kill malicious processes.

  • Delete or quarantine suspicious files.

  • Collect forensic data (e.g., memory dumps).

  • Upload tools for deeper investigation.

How to Use RTR:
  1. Go to Host Inventory → Click a Host → Click “Connect to Host (RTR)”.

  2. You must have RTR permissions in your role.

  3. You'll enter a session where you can type commands like:

    ps       # List processes
    netstat  # View network connections
    getfile  # Download a file from the endpoint
    
Security Features:
  • Sessions are logged.

  • Requires elevated privileges.

  • You can terminate the session at any time.

2. Network Containment

What is Containment?

This action isolates a host from the network, while still allowing it to communicate with Falcon Cloud.

Why Use It?
  • Stops lateral movement of threats.

  • Prevents ransomware from spreading.

  • Gives time to investigate without risking more damage.

How to Contain a Host:
  1. From the host details page, click “Contain Host”.

  2. A red banner will confirm containment is active.

  3. You can release it later with “Lift Containment”.

3. Sensor Update or Restart

  • If a host is running an outdated sensor version or experiencing issues, you can:

    • Trigger a sensor update manually.

    • Restart the sensor service from the console.

  • Useful after applying policy changes or during troubleshooting.

4. Trigger Diagnostic Logs

You can command a host to:

  • Send diagnostic logs to Falcon Support.

  • Help troubleshoot issues like sensor crashes or connectivity problems.

5. Add to Host Group / Change Tags

While not technically “actions” in the same way as RTR or containment, you can:

  • Reassign a host to a different group to change its policies.

  • Add or remove tags dynamically.

Example Scenario:

You receive an alert that malware was detected on a finance team laptop.

  • Step 1: Use the host filter to find the affected machine.

  • Step 2: Click “Contain Host” to isolate it.

  • Step 3: Launch an RTR session to check for suspicious files and processes.

  • Step 4: Pull logs or memory dumps for deeper analysis.

  • Step 5: After resolving the issue, lift containment and optionally update the sensor.

5. Host Settings Management

This section deals with how you can fine-tune and control host-level settings beyond the usual group-based policy management. It’s especially useful for unique environments or special-case hosts.

1. Local Overrides

What Are Local Overrides?

Local overrides allow a host to behave differently than what its group-level policy specifies.

Why Use Them?
  • For troubleshooting or testing.

  • To provide temporary exceptions for high-risk or specialized machines.

Example Use Case:

A developer machine in the R&D department needs to run unsigned code that would normally be blocked. You can apply a local override to reduce sensor strictness without changing policy for the whole group.

How to Apply:
  • In the host’s detail page, click “Actions” → “Edit Settings”.

  • Modify detection sensitivity, logging, or real-time protections.

Overrides are visible and auditable, but should be used sparingly.

2. Tamper Protection

What is Tamper Protection?

Tamper Protection prevents local users—even administrators—from:

  • Uninstalling the sensor.

  • Stopping or modifying the sensor service.

Key Details:
  • Can be enabled per host or as part of a policy.

  • When enabled, a maintenance token is required to uninstall or stop the sensor.

Why Important?

Prevents attackers from removing protection after gaining local admin rights.

3. Host Rename Rules

CrowdStrike automatically identifies hosts by their hostname, but sometimes hostnames change—especially in VDI or cloud environments.

What Are Rename Rules?

Rules that:

  • Automatically update the display name in Falcon to reflect new hostnames.

  • Ensure data continuity (e.g., alerts stay associated with the correct machine).

Configuration Examples:
  • Use regular expressions to match and rename.

  • Create rules that extract machine name from asset tags or naming standards.

4. Host-Specific Policies

In general, policies are applied to groups, not directly to hosts. However:

  • If a host is moved to a group, it immediately inherits that group’s policy.

  • This is how you can manually reassign policy on a per-host basis—by changing group membership.

5. Host Tagging Automation (via API or Scripts)

Advanced users can:

  • Use scripts or external systems (like CMDB) to assign tags automatically to hosts via Falcon’s API.

  • Keep metadata up to date (e.g., business unit, owner, criticality).

Example Scenario:

You’re preparing for an audit, and one of your cloud servers has a sensor issue. You:

  1. Enable local override to temporarily reduce detection strictness.

  2. Enable tamper protection to prevent manual removal.

  3. Apply a rename rule to reflect the asset ID.

  4. Add tags for audit: Owner:Security, Env:Prod.

Summary:

Feature Purpose
Inventory View and manage all hosts
Filters & Tags Organize and search
Status Indicators Check host and sensor health
Host Actions RTR, containment, updates
Settings Management Overrides, protection, metadata

Host Management and Setup (Additional Content)

Filter engineering: turning “search” into a safe operational control

Why this matters (beyond convenience)

In Falcon administration, filtering is often the last safety barrier between “a targeted action” and “an accidental broad change.” Exam scenarios commonly test whether you can narrow scope confidently before taking any host-impacting step.

Advanced filtering strategy (high-signal host identification)

Use a “two-key confirmation” habit:

  • Start with a stable identifier (hostname pattern, device ID, or another durable attribute).

  • Confirm with a second attribute that is less likely to collide (OS, site, tags, last seen window, group membership).

Operational guardrails you can reuse:

  • Result-count sanity check: if your filter returns 10× more hosts than expected, treat it as wrong until proven otherwise.

  • Spot-check: open 2–3 random hosts from the filtered set and confirm they match the intended population.

  • Attribute stability awareness: avoid relying on frequently changing values (e.g., short-lived IPs) as the only selector.

Troubleshooting pattern: “I can’t find the host”

When “the host isn’t there,” separate these causes quickly:

  • Data mismatch (wrong hostname variant, renamed asset, duplicate naming pattern),

  • Lifecycle state (inactive/decommissioned),

  • Visibility issue (sensor not checking in or never registered).

Best next step is to widen cautiously: broaden the identifier, then re-add constraints one by one until the host appears.

Exam relevance & common traps

  • Trap pattern: choosing a broad filter and acting immediately. Better answers mention narrowing, result count validation, and spot-checking.

  • Trap pattern: relying only on IP. Better answers mention multi-attribute confirmation.

Frequently Asked Questions

What is the most common reason a Falcon sensor enters Reduced Functionality Mode (RFM)?

Answer:

The host operating system or kernel version is unsupported by the sensor.

Explanation:

Reduced Functionality Mode occurs when the sensor cannot fully operate due to compatibility limitations. A common cause is a Linux kernel version or operating system configuration not supported by the installed sensor version. In this state, the sensor continues basic telemetry reporting but disables advanced prevention or detection capabilities. Administrators should verify compatibility matrices and update either the operating system or the sensor version to restore full functionality.

Demand Score: 84

Exam Relevance Score: 86

How can administrators quickly identify hosts with inactive sensors in the Falcon console?

Answer:

By filtering hosts based on last seen time or sensor status in the Host Management page.

Explanation:

The Host Management page allows administrators to apply filters that highlight hosts with sensors that have not communicated with the cloud within a defined timeframe. Filtering by “last seen” or sensor status enables quick identification of inactive endpoints. This process helps security teams locate systems that may be offline, improperly configured, or experiencing communication issues. Regular monitoring of inactive sensors helps maintain endpoint visibility across the environment.

Demand Score: 80

Exam Relevance Score: 84

Why is host filtering an important feature in the Falcon Host Management page?

Answer:

It allows administrators to quickly locate endpoints based on operational or security conditions.

Explanation:

Large environments may contain thousands of endpoints. Filtering tools enable administrators to identify hosts based on attributes such as operating system, sensor version, host group membership, or activity status. This capability is essential for tasks such as identifying outdated sensors, locating systems requiring investigation, or verifying policy deployment across specific groups. Effective use of filtering significantly improves operational efficiency when managing large endpoint fleets.

Demand Score: 75

Exam Relevance Score: 80

What is the effect of disabling detections on a specific host in Falcon?

Answer:

The sensor continues monitoring activity but detection alerts are suppressed.

Explanation:

Disabling detections for a host prevents Falcon from generating detection alerts for events on that system. This option is sometimes used during troubleshooting or when investigating false positives affecting critical workloads. However, disabling detections reduces security visibility because malicious activity may occur without generating alerts. Administrators should use this configuration carefully and only temporarily while resolving specific operational issues.

Demand Score: 72

Exam Relevance Score: 82

Why do administrators regularly review inactive sensors in the Falcon console?

Answer:

To ensure all endpoints remain protected and communicating with the platform.

Explanation:

Inactive sensors indicate systems that have stopped communicating with the Falcon cloud. Causes may include system shutdown, network connectivity issues, sensor malfunction, or device decommissioning. Regular review helps administrators identify endpoints that may no longer be protected or visible to security monitoring. Maintaining active sensors ensures consistent threat detection coverage across the environment and helps identify operational gaps in endpoint protection.

Demand Score: 70

Exam Relevance Score: 78

CCFA-200 Training Course
$68$29.99
CCFA-200 Training Course