Falcon Orchestrator Demo With Evan Burns

Hi, I’m Even Burns security engineer at CrowdStrike. In this video demonstration, we’ll give you a brief overview of the Falcon Orchestrator tool and its capabilities. This tool solidifies CrowdStrike’s commitment to the open source community and will be maintained as an ongoing project. We welcome your contribution to the project by providing feedback, feature ideas, and code through the Get Help page.

So what is Falcon Orchestrator? The Falcon connect initiative exposes a robust set of APIs that can be used to integrate CrowdStrike data into other solutions in your technology ecosystem. By leveraging these APIs, Falcon Orchestrator is able to provide automated security-centric workflow and case management capabilities. It also enables you to take responsive actions and compromise end points by invoking evidence collection or mediation scripts through the PowerShell framework.

Now, let’s take a look at the tool. The first component of the tool provides efficient operational processes for managing security alerts from the Falcon O’s platform. By consuming the detection information, the API, the data can be enhanced through the addition of analyst annotations. This includes assigning individuals to an alert, setting a status, overriding with custom severities, and applying text. Falcon Orchestrator also integrates with Active Directory to provide you with more context around the impact of users, thus allowing analysts to make more informed decisions and prioritize alerts accordingly.

Another workflow feature allows for dynamic accountability assignment. In this part of the application, we’ll navigate to the Responder’s tab and create a new record. This is set up for each individual part of the security response team that will be responsible for investigating detection events. Now, that the user is registered in the system, we’ll set up the schedule.

On a per-day basis, we can assign one of our responders. This way the system will automatically reference this schedule and assign it to that responder accordingly. The common use case for any technology is the ability to classify and categorize assets and alerts for reporting and prioritization. By opening a detection event, we can see that the system is able to resolve the Active Directory OU this user is a part. of. We can now use this information and create a new taxonomy rule.

In creating a rule, we can apply regular expressions for username or host name or select an Active Directory, OU regroup. We can also set a taxonomy to a critical rating, thus raising the priority of any related alerts. Once the rule has been published in the system any associated detections will automatically be tagged and displayed to the analyst.

By navigating to the dashboard, we can also view detection accounts by each taxonomy rule that we’ve created. In addition to the taxonomies, we can define whitelisting rules to mark detections we know to be causing noise. This allows analysts to focus on violent security threats by more false positives.

As we can see, there are two detections and an open status for vssadmin. In creating a rule, we can define a regular expression for file name, file path, or command line or alternatively define a SHA-256 hash. We also provide a reason to keep an audit trail of why the rule is configured. Once we’ve created the rule, any existing and met new alerts will automatically be set to status of whitelisted.

Responding to a security incident typically involves taking a containment-based action to limit impact of the threat. A common response mechanism is to disable the credentials of any compromised accounts. By selecting the containment status in a detection workflow, we’re prompted with the ability to disable the user account and enforce a password reset.

As we can see, this account is currently active and functional within AD. By submitting the containment request, the system will reach back to Active Directory and lock down the account. This coupled with network containment of the compromised device through Falcon host significantly reduces the number of steps an analyst must perform during an incident thus reducing the overall time to containment and remediation.

Next up, we have the first forensic feature. The forensics module leverages PowerShell to execute commands on remote end points for response purposes. For steps on prerequisite configuration refer to the project’s Get Up page. File extraction allows the analyst to extract files from target systems to perform post analysis or collection of incident artifacts.

First we’ll navigate to the Forensics tab and select File Extraction. For this demonstration, we’ll extract a test text file from one of our Windows servers. We’ll need to input the host name or IP address of the end point and a full path to the target file we intend to extract. The server will then obtain metadata regarding that file and provide a link to the user to download the file.

This file will now be downloaded in the browser as a password-protected zip. This password is user configurable from within the Admin Configuration section of the web application. Upon unzipping the file, we can see that this is the same file and content that we had initially retrieved from the target Windows Server. We can also initiate a file extraction activity from a detection workflow. This limits the need to supply a host name and file path name information since it’s already provided within the detection details.

The second forensics feature allows analysts to browse the file system on a given end point to search for incident artifacts of interest. By providing the IP address or hostname of the system and an initial directory, we can begin traversing and searching directories on the file system. By executing a search, we get a full listing of the root C directory. In this case, we have located the same test.text file from our previous example.

We’ll switch over to the server to show that we are returning same results as executing a Get-ChildItem command locally. Switching back to the application, we can then begin drilling down into each directory to seek out any file-based artifacts of interest.

The last response feature, part of the initial release of Falcon Orchestrator, allows a user to query the registry of a system to get a listing of installed software. By providing, again, the IP address or hostname, we can execute a command to show the full listing of software names and versions. This can be helpful to identify vulnerable or authorized applications on an end point. As we can see, this for approx the same results as even programmed features within Windows.

These are only some of the initial features being released with Falcon Orchestrator. Thank you for watching and please remember that the continued success of this project will rely on your involvement and contributions. If you have any feedback or simply want to chat further on integration capabilities, please reach out through the Get Help page or community forums at community.crowdstrike.com.