CCFA-200 User Management

User Management Detailed Explanation

1. User Accounts

What is a User Account in Falcon?
A User Account allows a person to log into the Falcon platform. Each account is tied to an email address, and it defines what that person can do within the system based on assigned roles.

How to Create a User Account (Step by Step):

1. Login to the Falcon Console:
   Go to falcon.crowdstrike.com and sign in using your administrator credentials.

2. Navigate to User Management:
   On the left-hand menu, go to:
   “Settings” → “User Management” → “Users”.

3. Click “Add User”:
   You will be asked to enter:

   • Email address (this becomes their username)

   • First and last name (optional)

   • Role (we’ll explain roles next)

   • Expiration date (optional – can auto-disable the account later)

   • Enforce MFA (Multi-Factor Authentication – highly recommended)

4. Send Invitation:
   Once the user is added, they receive an email invitation to set up their password and MFA, and then access the platform.

Tips for Beginners:

• Each user must have a unique email address. No sharing.

• Don’t give everyone the Admin role. It’s safer to use the minimum necessary permissions.

• If a user leaves the company, go to User Management and disable or delete their account.

2. Roles and RBAC (Role-Based Access Control)

What is RBAC?
RBAC stands for Role-Based Access Control. This means that what a user can do in Falcon depends on their role. Each role has a list of permissions—what parts of the platform they can see, and what actions they can perform.

Predefined Roles in Falcon

CrowdStrike provides some built-in roles that you can use right away:

1. Administrator:

   • Full access to everything.

   • Can manage users, policies, detections, and configurations.

   • Should be given only to trusted senior users.

2. Analyst:

   • Can view and investigate detections.

   • Cannot change user settings or policies.

3. Investigator:

   • Similar to Analyst, but with slightly fewer permissions.

   • Focused on viewing, not editing.

4. Real Time Response (RTR) Admin:

   • Can access and use the Real Time Response shell.

   • This is a powerful role—RTR lets you run commands on machines remotely.

5. Dashboard Viewer / Read-only Roles:

   • Can view dashboards and reports but can’t make changes.

   • Useful for auditors or managers.

Custom Roles

If the built-in roles don’t fit your needs, you can create a custom role.

Steps to create a custom role:

1. Go to: Settings → User Management → Roles

2. Click "Create Role"

3. Select or deselect permissions. Examples:

   • “Can edit detection policies”

   • “Can manage user accounts”

   • “Can use Real Time Response”

4. Name your role and save it.

Example:

You might want to create a role called “Policy Manager” that allows users to edit policies but not change user settings or access API keys.

Why Use RBAC?

RBAC is critical for security and compliance:

• Limits mistakes by junior staff.

• Prevents sensitive data exposure.

• Meets audit requirements (especially in regulated industries like finance and healthcare).

3. MFA and Security

What is MFA (Multi-Factor Authentication)?
MFA is a security feature that requires a user to provide two or more pieces of evidence (factors) to verify their identity when logging in.

In Falcon, the two factors are usually:

1. Something you know – your password.

2. Something you have – like a code from an authenticator app (e.g., Google Authenticator or Microsoft Authenticator).

Why is MFA Important?

MFA protects your environment from:

• Phishing attacks (if a password is stolen, it’s not enough on its own).

• Unauthorized access to the Falcon console.

• Compliance issues, especially for SOC 2, HIPAA, or GDPR.

How to Enable MFA in Falcon

There are two ways to require MFA:

1. When creating a user:

• In the "Add User" screen, check the box “Require MFA”.

• The user must then set up MFA during their first login.

2. For existing users:

• Go to User Management → Users → Edit User.

• Check the “Enforce MFA” option and save.

Security Settings for User Accounts

In addition to MFA, Falcon offers other important settings:

1. Password Policies

• You can define how complex passwords must be:

  • Minimum length

  • Must include numbers/symbols

  • Cannot reuse recent passwords

2. Session Timeout Settings

• Falcon can log users out after a period of inactivity.

• This reduces the risk of someone accessing an unattended workstation.

3. IP Whitelisting (optional via API integration)

• You can restrict logins to specific IP addresses for enhanced control.

4. Email Alerts for Login Activity

• Some organizations set alerts when an admin logs in or a failed login occurs.

Security Tip for Beginners:

Even if MFA is optional for some users, it is highly recommended to make it mandatory for:

• All admins

• Anyone with access to policies or sensitive data

• Users with RTR privileges

4. Audit Logs

What are Audit Logs?
Audit logs are records of user actions within the Falcon console. They are essential for tracking activity, investigating incidents, and ensuring accountability.

Why Are Audit Logs Important?

Audit logs help you:

• See who did what and when (e.g., user logins, policy changes).

• Detect unauthorized or suspicious activity (e.g., a user changing API keys unexpectedly).

• Meet compliance and regulatory requirements (e.g., for SOC 2, ISO 27001).

• Reconstruct a timeline during a security investigation.

Where to Access Audit Logs in Falcon

1. Log into the Falcon Console.

2. Go to “Audit Logs”, usually found under:

   • Settings → Audit Logs, or

   • Activity → Audit Log (depending on your role and console version).

What Information Do Audit Logs Contain?

Each entry in the audit log includes:

• Timestamp – exact date and time of the action.

• Username – who performed the action.

• Action Taken – e.g., “Created a new policy”, “Generated an API key”.

• Target Resource – what was affected, such as a user account, sensor policy, or host group.

• Result – success or failure of the action.

• IP Address – location from which the user performed the action.

Common Logged Events

• Logins and logout activity (including failed attempts)

• Changes to user roles or accounts

• API credential creation or deletion

• Policy edits or assignments

• Detection suppression rule changes

• RTR session start and end times

Filtering and Searching Audit Logs

The Falcon audit log interface allows you to:

• Filter by time range, user, or action type

• Search for specific keywords (e.g., “API key”, “policy”)

• Export logs for long-term storage or external analysis (CSV or via API)

Example Use Case:

Imagine a detection was suppressed unexpectedly. You can:

• Go to the audit logs.

• Search for "Suppression".

• Find out who added the rule, when, and what detection ID was affected.

5. API Credentials

What Are API Credentials in Falcon?
API credentials allow external systems (like SIEM tools, custom scripts, or security automation platforms) to communicate securely with the Falcon platform.

These credentials are like “digital user accounts” for software, not people.

Why Use API Credentials?

They are used to:

• Automate threat detection or response workflows.

• Pull data (like host inventory, detection details, or audit logs).

• Integrate Falcon with tools like Splunk, ServiceNow, or custom dashboards.

Types of API Credentials

Each API credential consists of:

1. Client ID – like a username.

2. Client Secret – like a password (only shown once, so store it securely).

3. Permission Scopes – these define what the API can access or do.

How to Create API Credentials (Step by Step)

1. Log into the Falcon console.

2. Go to Support → API Clients and Keys.

3. Click “Create API Client”.

4. Give it a name and optionally a description.

5. Assign permission scopes. Examples:

   • Read Detections

   • Write to Host Groups

   • Read Audit Logs

6. Click “Create”. The Client ID and Client Secret will appear—copy them immediately (you cannot view the secret again).

7. Save them securely (e.g., in a password manager or environment variable).

Best Practices for Managing API Keys

• Use minimum permissions needed. Don’t give full access unless required.

• Rotate API keys regularly. This improves security and helps prevent misuse.

• Assign each system a unique API credential. This makes auditing easier.

• If a key is compromised, immediately delete and recreate it.

Auditing API Usage

• API actions (like detection queries or host updates) are recorded in the Audit Logs just like user actions.

• You can track who used an API key, from what IP, and what actions they performed.

Summary

• API keys are for software access, not human users.

• Always limit scopes and store secrets safely.

• Regularly review and rotate credentials.

• Audit usage through the Falcon console.

User Management (Additional Content)

Advanced role design: mapping jobs to console capabilities (least privilege in practice)

Why this matters beyond “give the SOC a role”

In real Falcon operations, the risk isn’t only “unauthorized access”—it’s mis-scoped access: someone can see what they need but can’t complete a workflow, or someone can change something they shouldn’t. The exam often expects you to choose the smallest permission set that still completes the task.

Practical mapping approach (from tasks → permissions)

Use a two-step mapping method that avoids “make them admin” shortcuts:

• Step 1: Write the task list in verbs (view detections, investigate host, run RTR command, edit policy, manage users, create API client).

• Step 2: Assign permissions to the verbs, not the title. Titles vary by org; verbs are stable.

A simple “starter mapping” you can reuse:

• SOC Analyst (triage/investigate): view detections/incidents, pivot to host details, run investigation actions allowed by policy; avoid policy-edit and user-management rights.

• Threat Hunter (deep investigation): broad visibility/search and investigation tooling; still avoid tenant-wide settings changes unless explicitly required.

• Falcon Admin (platform changes): policy creation/tuning, sensor update control, configuration settings; keep this group small.

• IT / Endpoint Ops (deployment health): sensor deployment visibility, host health, troubleshooting views; avoid security tuning capabilities unless needed.

• Auditor / Read-only: reporting and visibility only; no change capability.

• Integration Engineer (API): API client permissions limited to the integration’s read/write needs; no interactive console admin rights unless required.

Validation pattern: “Can they do the job without extra power?”

A safe validation routine:

1. Ask: “What is the single action they must perform that currently fails?” (view vs change vs execute).

2. Confirm role assignment and re-test the exact action.

3. If adding permissions, add the narrowest missing capability, then re-test—do not jump to broad roles.

4. Record the reason and the change owner (auditability).

Exam relevance & common traps

• Trap pattern: Correct task, wrong scope (granting a role that can edit policy when the scenario only needs investigation).

• Trap pattern: Confusing visibility with execution (a user can see an RTR panel but cannot run a command; the fix is role capability, not reinstalling sensors).

• Your best answer usually mentions least privilege + validation (“grant only what’s needed and confirm via the exact failing action”).