CrowdStrikeCCFA-200b91 concepts

CCFA-200b Cheat Sheet

Quick reference for the CrowdStrike Certified Falcon Administrator exam.

Quick Navigation

User and Access Management Sensor Deployment — Windows Sensor Deployment — macOS and Linux Sensor Update Policies Prevention Policy Settings Exclusion Types Allowlists and Blocklists Host Groups and Policy Assignment Device Control and Firewall Real Time Response (RTR)Containment and Response Detection and Alert Management Falcon Console Navigation Reporting and Dashboards Falcon Platform Modules

User and Access Management

Falcon Administrator Role: Full console access including policy management, user administration, sensor deployment, and all configuration settings. The highest predefined role.
Falcon Analyst Role: Access to investigate and triage detections, view host details, and perform basic investigation tasks. Cannot modify policies or manage users.
RTR Active Responder Role: Can initiate Real Time Response sessions with read-only and basic remediation commands. Cannot run custom scripts or upload files.
RTR Administrator Role: Full RTR access including custom scripts, put commands, file uploads, and all write operations. Superset of RTR Active Responder permissions.
RBAC (Role-Based Access Control): Assign predefined or custom roles to users controlling what they can see and do in the Falcon console. Roles are additive — multiple roles combine permissions.
SSO/SAML Configuration: Single Sign-On integration with organizational identity providers (Okta, Azure AD, etc.). Always maintain at least one local admin for break-glass access.
API Client Management: OAuth2 API clients created in the console for programmatic access. Each client has specific scopes (read/write per resource type). Follow least privilege.
Falcon Investigator Role: Deep investigation and threat hunting access — event search, process timelines, and raw telemetry. More than Analyst but cannot modify policies or manage users.
Multi-Factor Authentication: MFA enforcement for console access adds a second authentication factor. Can be enforced organization-wide or per-role.

Sensor Deployment — Windows

Windows Prerequisites: Administrator privileges required. No .NET dependency. Supported on Windows 7+ and Server 2008 R2+. No reboot required after installation.
CID (Customer ID): Unique identifier that registers the sensor with your Falcon tenant. Required during installation. Includes a checksum suffix for validation.
Silent Install (Windows): WindowsSensor.exe /install /quiet /norestart CID=<your_cid> — installs silently without user interaction or reboot.
Proxy Configuration: For endpoints that cannot reach CrowdStrike cloud directly: specify proxy settings during installation or configure via policy after deployment.
GPO/SCCM/Intune Deployment: Enterprise deployment tools push the sensor installer with CID parameter to endpoints at scale. Sensor begins protecting immediately after install.

Sensor Deployment — macOS and Linux

macOS Prerequisites: Requires system extension approval (SEXT). Deploy MDM profile via Jamf/Intune BEFORE sensor installation to auto-approve the extension.
macOS MDM Profile: PPPC (Privacy Preferences Policy Control) and System Extension profiles must be deployed via MDM. Without them, sensor runs in reduced functionality.
Linux Prerequisites: Verify kernel compatibility with the sensor version before deployment. Not all kernel versions are supported. Check the Falcon support matrix.
Linux Installation: Install via package manager (dpkg, rpm, yum, apt). Set CID with: sudo /opt/CrowdStrike/falconctl -s --cid=<your_cid>
Reduced Functionality Mode (RFM): Sensor is running but with limited capability. Common cause on Linux: unsupported kernel version. Common cause on macOS: unapproved system extension.
Sensor Uninstall Token: Anti-tamper protection. An uninstall token from the Falcon console is required to remove the sensor. Prevents adversaries from disabling protection.

Sensor Update Policies

N (Latest Version): Endpoints receive the newest sensor version as soon as it is released. Best for test/dev environments. Risk: untested version in production.
N-1 (Previous Version): Endpoints receive the version one release behind the latest. Recommended for production — allows time for the latest version to be validated.
N-2 (Two Versions Back): Endpoints receive the version two releases behind the latest. Most conservative option for critical production systems.
Build Pinning: Pin endpoints to a specific sensor build version. Prevents any automatic updates. Used for tightly controlled environments.
Maintenance Windows: Schedule sensor updates during defined time windows to minimize impact on business operations. Updates only apply during the window.
Staged Rollout Best Practice: Use N for test group, N-1 for general production, N-2 for critical servers. Validate each version before promoting to broader groups.

Prevention Policy Settings

Cloud ML Detection: Machine learning analysis performed in CrowdStrike cloud. Levels: Disabled, Cautious, Moderate, Aggressive, Extra Aggressive. Requires cloud connectivity.
Sensor ML Detection: Machine learning analysis performed locally on the endpoint. Same slider levels as Cloud ML. Works offline — critical for intermittently connected hosts.
Cloud ML vs Sensor ML: Cloud ML: deeper analysis, requires connectivity. Sensor ML: local analysis, works offline. They are INDEPENDENT settings — configure both separately.
Exploit Mitigation: Protects against memory-based exploits: stack pivot, heap spray, code injection, return-oriented programming (ROP). Enable for all endpoints.
Script-Based Execution Monitoring: Monitors and can prevent malicious scripts: PowerShell, WScript, CScript, VBScript, macros. Detects living-off-the-land techniques.
Behavioral IOA Prevention: Blocks processes exhibiting malicious behavioral patterns defined by CrowdStrike Intelligence. Pattern-based, not hash-based.
Adware/PUP Detection: Detects potentially unwanted programs and adware. Can be set to detect-only or prevent. Often causes false positives with legitimate tools.
Detect vs Prevent Mode: Detect: alerts but does NOT block. Prevent: actively blocks. ALWAYS start new settings in Detect mode and tune before switching to Prevent.

Exclusion Types

IOA Exclusions: Suppress Indicator of Attack (behavioral) detections for specific files, paths, or processes. Use when legitimate software triggers behavioral rules.
ML Exclusions: Suppress machine learning (cloud ML and sensor ML) verdicts for specific files. Use when legitimate files are repeatedly flagged by ML engines.
Sensor Visibility Exclusions: NUCLEAR OPTION: Prevents the sensor from monitoring a file/path entirely. No telemetry collected. Use ONLY for severe performance impacts.
Exclusion Hierarchy: Prefer IOA/ML exclusions first (targeted, preserves telemetry). Sensor visibility exclusions are last resort (eliminates all visibility).
Exclusion Scope: Exclusions can be scoped to specific host groups or applied globally. Scope them as narrowly as possible to maintain security.

Allowlists and Blocklists

Allowlist (Global): Always allow a file by SHA256 hash across ALL endpoints and ALL detection engines. Bypasses cloud ML, sensor ML, IOAs, and IOCs. Use sparingly.
Blocklist (Global): Always prevent a file from executing by SHA256 hash across ALL endpoints. Overrides any policy settings. Use for known-bad IOCs.
Allowlist vs Exclusion: Allowlist: global, by hash only, bypasses everything. Exclusion: can be path-based, behavior-based, scoped to groups, more granular.
Hash-Based Identification: Both allowlists and blocklists use SHA256 hashes. If a file is modified (even one byte), the hash changes and the list entry no longer applies.
Certificate-Based Allowlisting: Allow files signed by a specific certificate (issuer + subject). Hash-independent — covers all versions of a legitimately signed application automatically.

Host Groups and Policy Assignment

Static Host Groups: Manually add/remove specific hosts. Membership is fixed until an admin changes it. Best for small, well-defined sets of endpoints.
Dynamic Host Groups: Rule-based membership using host properties: hostname pattern, OS type, OU, site, sensor tags. Hosts auto-join/leave as properties change.
Sensor Tags: Custom tags applied to sensors during or after installation. Used in dynamic host group rules for flexible grouping (e.g., environment=prod).
Policy Assignment: Policies are assigned to host groups. A host inherits the policy of its assigned group. Multiple group memberships trigger precedence rules.
Policy Precedence: When a host matches multiple policies, the FIRST policy in the ordered list wins. Admins control precedence by reordering policies. NOT most-restrictive-wins.
Default Policy: Every policy type has a default that applies to hosts NOT covered by any specific host group assignment. Always configure defaults with baseline security.

Device Control and Firewall

USB Device Control: Policy controlling USB mass storage device access: allow, block, or read-only. Can create exceptions by vendor ID, product ID, or serial number.
Device Control Scope: Applies to USB mass storage devices by default. Does NOT control other USB classes (HID, audio) unless specifically configured.
Falcon Firewall Management: Centralized host-based firewall management. Create and deploy firewall rules across endpoints from the Falcon console.
Firewall Rule Ordering: Rules evaluated top-down, first match wins. A broad ALLOW rule placed above a specific DENY rule will allow the traffic. Order matters.
Firewall Rule Groups: Organize firewall rules into logical groups for easier management. Groups can be assigned to different host groups.

Real Time Response (RTR)

RTR Requirements: Two conditions must be met: (1) RTR enabled in the response policy AND (2) user has an RTR role assigned. Missing either prevents access.
RTR Active Responder: Read-only and basic remediation commands: ls, cd, cat, reg, ps, netstat, filehash, getsid. Cannot upload files or run custom scripts.
RTR Administrator: ALL Active Responder commands PLUS: put (upload files), run (custom scripts), runscript, and advanced write operations.
RTR Custom Scripts: Pre-uploaded scripts that RTR Administrators can execute on endpoints. Must be uploaded and approved before use in a session.
RTR Use Cases: Remote investigation (view processes, files, registry), remediation (kill processes, delete files), evidence collection, and live forensics.

Containment and Response

Network Containment: Isolates a compromised host from the network. The host can ONLY communicate with CrowdStrike cloud (plus IP exclusions). All other traffic blocked.
IP Exclusions for Containment: Specify IP addresses that remain accessible during containment (e.g., DNS server, critical internal services). Must be configured BEFORE containing.
Containment Limitations: Contained hosts cannot access internal resources unless IP-excluded. Users on the host lose network access. Plan IP exclusions before containment.
Lift Containment: Restores full network connectivity to a contained host. Only do this after investigation and remediation are complete.
Quarantine Management: View quarantined files in the console. Release false positives back to original location. Always add to allowlist BEFORE releasing to prevent re-quarantine.

Detection and Alert Management

IOA (Indicator of Attack): Behavioral detection: identifies malicious patterns regardless of specific malware. Based on tactics, techniques, and procedures (TTPs).
IOC (Indicator of Compromise): Signature/indicator-based: matches specific known artifacts — SHA256 hashes, domains, IP addresses uploaded to Falcon.
Custom IOA Rules: Admin-created behavioral detection rules for organization-specific threats. Can be set to detect-only or prevent. Always test in detect mode first.
Custom IOC Uploads: Upload known-bad hashes, domains, or IPs with assigned actions (detect or prevent) and severity levels. Support optional expiration dates.
Detection Severity Levels: Informational, Low, Medium, High, Critical. Set by CrowdStrike Intelligence based on threat analysis. Admins cannot change severity.
Alert Triage Workflow: Review detection > analyze process tree > determine true/false positive > assign status > create exclusion if false positive > close.
False Positive Handling: Mark detection as false positive AND create appropriate exclusion. Marking alone does NOT prevent future detections of the same activity.

Falcon Console Navigation

Activity Section: Real-time detections dashboard, detection trending, and activity overview. Primary location for viewing and triaging security alerts.
Investigate Section: Deep investigation tools: search by host, hash, IP, user, domain. Event search for raw telemetry. Falcon Insight process timeline.
Host Management: View all managed endpoints: sensor version, OS, last seen, applied policies, host group membership. Filter by status and properties.
Configuration Section: All policy management: prevention, sensor update, device control, firewall, response policies. Also host groups, exclusions, and allowlists.
Process Tree Analysis: Visual representation of process execution chain in a detection. Red-highlighted node indicates where malicious behavior was detected.
Support and Resources Section: Contains documentation, release notes, API documentation, and community resources. Also the entry point for contacting CrowdStrike support.

Reporting and Dashboards

Custom Dashboards: Create dashboards with widgets showing detection trends, sensor health, host coverage, and security posture. Customizable layout and data sources.
Scheduled Reports: Configure recurring reports delivered via email. Set frequency (daily, weekly, monthly), content, and recipient list.
Sensor Health Monitoring: Monitor offline sensors, RFM hosts, sensors needing updates, and coverage gaps. Key metrics for maintaining security posture.
Audit Logs: Track all administrative actions: policy changes, user creation/modification, exclusion changes, API client operations. WHO did WHAT and WHEN.
Data Retention: Dashboard and detection data has a platform retention period. For longer retention, use Falcon Data Replicator (FDR) to export to external storage.

Falcon Platform Modules

Falcon Prevent: Next-generation antivirus (NGAV) module. ML-based and behavioral detection/prevention. The core protection component.
Falcon Insight (EDR): Endpoint Detection and Response. Full telemetry collection, threat detection, investigation tools, and response capabilities.
Falcon Spotlight: Vulnerability management using existing sensor data. Identifies CVEs without additional scans. Scanless vulnerability assessment.
Falcon Discover: IT hygiene and asset discovery. Identifies unmanaged assets, applications, and accounts. Highlights sensor coverage gaps.
Falcon OverWatch: Managed threat hunting SERVICE (not a product feature). Human analysts proactively hunt for adversaries 24/7.
Falcon Data Replicator (FDR): Streams raw event data to external storage (S3, Azure Blob) for long-term retention and SIEM integration.
Falcon Identity Protection: Identity-based threat detection for Active Directory, Azure AD. Monitors identity infrastructure beyond just endpoints.
CrowdStrike Store: Marketplace for third-party integrations extending Falcon capabilities. Apps may require separate licensing.

Ready to test yourself?

Start a timed CCFA-200b mock exam or review practice questions by domain.