Installation & Deployment
Falcon Orchestrator has only been tested on Windows Server 2012 R2, however it should also be functional on an older versions of Windows Server as long as .NET 4.5 framework is installed. It can be deployed on a single host running or across multiple servers.
Database Server – Ensure that a MS SQL Server database engine is installed on the server. It is suggested, although not required, to utilize an enterprise version as future updates will take advantage of SQL Server CDC functionality which is not available with the SQL Server Express editions. The software has only been tested with SQL Server 2014.
Web Server - The following Windows server roles must be installed:
- Web Server (IIS) > Web Server > Security > Windows Authentication
- Web Server (IIS) > Web Server > Application Development > ASP.NET 4.5
- Application Server > .NET Framework 4.5#
The project contains an MSI installer which is designed to handle all deployment related tasks. As new bug fixes, major features and changes are released an updated installer package version will be provided. Before beginning the installation, ensure you have all the aforementioned dependencies in place otherwise the setup will fail. Download the most current version of the installer here.
-
Execute the MSI installer on the host that will be running the full application or if using a distributed deployment on the web server host.
-
Select the path to install Falcon Orchestrator's web application. By default the web app is installed to
C:\Inetpub\Falcon Orchestratorand the client service toC:\Program Files (x86)\Falcon Orchestrator -
Next you will be prompted to supply the initialization configuration settings. These settings will be used to update the web and service configuration text files with initial values. If you wish to changes these in the future, you can simply modify the configuration files as needed.
| Database Server Name Or IP | If the database server resides on the same host as the installer you can supply localhost or the hostname of the server. When using localhost, you must first enabled TCP/IP within SQL Server Configuration Manager. If the database will reside on a separate server, supply the IP address or hostname accordingly. |
| Database Name | Name of database to be created. Defaults to FalconOrchestrator. |
| Database Login Username | The username of an account which has sufficient permissions to create and alter a database on the database server. |
| Database Login Password | The password of an account which has sufficient permission to create and alter a database on the database server. |
| Encryption Key | Key used to encrypt/decrypt sensitive data stored in the SQL database. |
| Allowed Users | Falcon Orchestrator leverages integrated Windows Authentication for maintaining access to the the web application. By default, all users are denied access to the system. Supply a comma delimited list (for multiple users) following the format of domain\username to allow access to these accounts. To add additional accounts in the future, modify the web.config file in the web application directory. |
- Click Next followed by Install to begin the install process. You will be prompted for UAC validation. If successful, the process will take a couple seconds and provide a confirmation message that the application has been successfully installed.
Upon successful installation, navigate to IIS Manager to ensure that the new site FalconOrchestrator has been deployed. This is where port binding and SSL based configuration changes can be made.
NOTE: By default the web application is installed on port 80 with regular HTTP. It is highly recommended you enforce the application to use SSL and import a certificate to be used. There are various resources on the internet to guide you through this process.
To verify the database and associated tables were created, upon SQL Server Management Studio and connect to the SQL database engine being used. A database with the name supplied during installation has now been created as seen below. For more information regarding the database structure, refer to the database schema wiki page.
The Falcon Orchestrator client executable and dependent libraries by default are setup in the directory C:\Program Files (x86)\Falcon Orchestrator. The Windows service is also configured by the installer. To confirm this, open Windows services and you should see a service with the name of Falcon Orchestrator Client.
The service is installed with a manual start type. We will first need to configure some settings within the Web application prior to starting the service.
Now that the MSI installer has successfully completed we will need to configure some items through the Falcon Orchestrator web application prior to starting the client service. As we’ve seen, the installer took care of deploying the IIS web application. As such we can now navigate to the web app by browsing to http://localhost from the local server or to the server IP/hostname from a remote system. If you have modified the web app to use a different port and/or SSL browse to that URL.
Through the navigation bar on the top browse to Admin > Configuration. This view displays the various configuration settings that we need to supply in order to get full functionality out of the system.
Integration into your email environment allows Falcon Orchestrator to send email notifications for new detection alerts or when tickets are generated and dispatched to a recipient. You will need to supply the hostname or IP address and port of your email server. Most email servers will also require you to authenticate prior to sending email message, provide those credentials in this section as well. These settings only need to be configured if you intend to use the notification capabilities as outlined below.
Issued whenever a new detection event is generated from the Falcon Host platform and consumed by the Falcon Orchestrator client service. The email notification is the last processing rule to execute. As such, any events matching a whitelisting rule will not result in an email notification. Also, taxonomy rules are applied first and therefore can upgrade a detection severity if the matched rule is defined as critical.
The ticketing module allows you to generate tickets for actions such as re-imaging/remediation, further investigation or any other purpose you see fit. More details on this are covered in the Ticketing section. Each type of notification has its own template associated with it. This is formatted in HTML and will be used as the body of the email message. You need to supply the full path to the template files located on the Falcon Orchestrator server.
When you provide one of the following values in an email HTML template or the subject field. The result will dynamically be resolved based on the corresponding detection or ticket. For example, supplying a subject of A {{Severity}} Severity Detection on {{Username}}\ {{Hostname}} would resolve to A High Severity Detection on jdoe\home-pc. Any values highlighted in blue are only resolved if the Active Directory Lookup rule is enabled and successfully resolves metadata for the associated user account.
| {{Severity}} | The custom severity rating of the detection, defaults to rating provided by CrowdStrike. |
| {{DetectionDescription}} | The description of the detection, providing details of the activity that is being alerted on. |
| {{Hostname}} | The hostname of the computer detection was seen on. |
| {{IPAddress}} | The IP address of the computer detection was seen on. This is only provided if the DNS lookup processing rule is enabled and is able to resolve the hostname to and IP. |
| {{ProcessStartTime}} | The start time of the process identified in the detection event |
| {{ProcessEndTime}} | The end time of the process identified in the detection event |
| {{FileName}} | The file name of the process identified in the detection event. |
| {{FilePath}} | The file path of the process identified in the detection event. |
| {{FalconOrchestratorLink}} | The URL to the detection edit view within the Falcon Orchestrator web application |
| {{FalconHostLink}} | The URL to the detection event in the Falcon Host UI. |
| {{Username}} | The user account name identified in the detection event |
| {{FirstName}} | The first name of the user associated with the account. |
| {{LastName}} | The last name of the user associated with the account. |
| {{Department}} | The department of the user associated with the account. |
| {{JobTitle}} | The job title of the user associated with the account. |
| {{EmailAddress}} | The email address of the user associated with the account. |
| {{Manager}} | The email address of the manager of the user associated with the account. |
| {{Country}} | The country of the user associated with the account. |
| {{StateProvince}} | The state or province of the user associated with the account. |
| {{City}} | The city of the user associated with the account. |
| {{StreetAddress}} | The street address of the user associated with the account. |
| {{PhoneNumber}} | The phone number of the user associated with the account. |
Integration to active directory enables a number of workflow & management capabilities within Falcon Orchestrator. In order to enable this functionality, you will need to supply the required information by navigating to Admin > Configuration > Active Directory. Currently AD integration only supports one domain/LDAP server. Future updates will provide support for multi-domain/forest based environments. Configuring these settings is only required if you intend to leverage the AD based features. More details, regarding how AD is used, can be found under the Active Directory wiki page.
| Server | Hostname or IP address of the LDAP server, |
| Username | Username for the credentials being used to integrate with AD. |
| Password | Password for the credentials being used to integrate with AD. |
| Description | The text that is used to update the Description attribute of the account in Active Directory when a containment action is taken. This should be some standard messaging to provide a rationale of the why account was disabled, etc. |
| Days Valid | Number of days locally stored account information is considered valid. Defaults to 30 days, if a detection occurs for an account which has not been updated in the database in X number of days, a new call to Active Directory is made for updated metadata. |
Falcon Orchestrator was developed as an extension to the Falcon Host Platform. The primary workflow is initiated by detection events from Falcon Host. As such, before we can start consuming these detection we need to supply the system with the credentials used to the connect to Falcon's API's. There are currently two groups of API's exposed by the Falcon Host Platform:
The streaming API is responsible for providing detection data via a firehose based API mechanism. This is a persistent stream of data, the client establishes a connection to the API endpoint and the connection is kept alive even when no detections are observed. This allows for a more real-time experience than relying on traditional polling. For additional implementation and usage details of the this API, refer to the Falcon Streaming API Reference document that can be downloaded through the Falcon Host API.
Navigate to Admin > Configuration > Falcon Streaming API and input your credentials:
A common use case for any security team is the need to search across their environment for known indicators of compromise. Although this is a more reactive approach to security, and should not be the only mechanism in place to identify malicious activity, it serves as a means to validate your environment against the known bad. The Falcon Host Platform allows users to upload their own list of indicators and configured them in such a way that a detection will be triggered whenever activity to that IOC is observed. This IOC management functionality is the first feature exposed through Falcon Orchestrator. The API also allows users to programmatically search for indicators and drill down to the machine and process level to garner more context around the threat. Additional details can be found on this by reading the Falcon Host API Reference accessible through the Falcon Host UI.
Navigate to Admin > Configuration > Falcon Query API and input your credentials:
These rules are used by the Falcon Orchestrator client service when processing detection events from the Falcon Streaming API. Once enabled, the client will apply the corresponding set of logic to each detection that it processes. Enable the rules you wish to use prior to starting the client service. It is suggest to not enabled email notification for the first time you start the service, otherwise will create a mail storm! Also, be aware that enabling each rule will impact the overall speed/performance of the client as it must execute additional logic for each rule. Notably, the DNS Resolution rule can add significant overhead as it must wait for a response before proceeding.
| Rule | Description |
|---|---|
| Assign Responder | This rule requires that responders be created and a schedule be populated as outlined below. When the rule is enabled, the client service will refer to the schedule database table and assign the appropriate responder based on the date the detection event occurred. This automates the process of maintaining accountability across the response team. |
| DNS Resolution | At times the detection data provided does not include a source IP address if no network connection events were seen as part of the detection. By enabling the DNS resolution rule the client will perform a DNS lookup for each hostname and save the first returned IP address. This does add overhead to the performance and processing time of the client. If using this functionality you should also ensure that the Falcon Orchestrator host OS has all the appropriate DNS suffixes configured. |
| Active Directory Lookup | When this rule is enabled, the client will perform a query against Active Directory for the given user account name. If the account is found within the AD database, the metadata is returned back to the server and saved within the database. This includes information such as; department, job title, location, AD OU, AD group memberships, manager email, etc. |
| Taxonomize | The concept of taxonomies is outlined in further detail on the Taxonomies page. With this rule enabled each detection will be checked for a match against all defined taxonomy rules. If there is a match the detection has the taxonomy associated with it and may be elevated to a critical severity if the matched taxonomy is defined as critical. |
| Whitelisting | Whitelisting is defined in further detail below. When enabled, each detection event is checked against all whitelist rules. If the detection matches a rule, it is set to a status of Whitelisted and a closed date of the current date/time. Whitelisted detections will not result in an email notification being sent. |
| Notification | If you wish to have email notification sent for each detection event, you must enable this rule. If enabled, the Email configuration settings need to be configured. Notifications are sent to the email address of the assigned responder. If no responder is assigned it is sent to the provided team email address. The team email address is also cc’d on all email notifications for tracking purposes. |
| Notification Threshold | This defined a severity threshold for which email notifications will be sent. The value selected will be the minimal severity required to generate a notification. For example, if you select medium, all medium, high and critical detections will result in a notification being sent. |
To make use of the Assign Responder process rule you will need to add responders to the system and subsequently populate the rotation schedule. Each individual part of the response team is considered a responder. They are typically members of a SOC or IR team, however can be any individual or team responsible for responding to Falcon Host detection events. To create a responder in the system, navigate to Admin > Responders > Create. From this view, you can create a new record. Note the email address supplied is the destination email that will be used for any alerts when the notification rules is enabled. Once the responder is created it will populate the dropdown within the edit view of a detection & the schedule section outlined below.
.
Now that we have created a responder we can modify the rotation schedule to define which responder is accountable for detection events per day of the week. This automatically assigns the appropriate responder to each detection event based on the Process Start Time of the detection event. If no responder is assigned for a given date, the detection will not have a responder assigned.
The Forensics component stores artifacts in the App_Data\Artifacts directory in the web application directory, by default this is located at C:\inetpub\Falcon Orchestrator\App_Data\Artifacts. By default directory will not allow the application account to write files to it. As such you will need to modify the permissions on this directory to all read & write access for the IIS account, which defaults to IISAppPool\FalconOrchestrator.
Now that everything is initialized when can begin the client windows service to begin consuming detection events. First we will need to modify the properties of the service and set the recovery options such that the service will restart itself if it fails. You should at a minimum set first and second failures to Restart the Service. After two attempts the service will no longer run and will require manual intervention to restart it. If you wish the indefinitely have the service restart itself, set the subsequent failures option to Restart the Service as well. If there is an error preventing the service from executing this will however result in the service continually retrying. As such you may want to set the Restart service after option to a higher threshold.
If the service stops functioning refer to the file in C:\Program Files (x86)\Falcon Orchestrator\RunLog.txt for troubleshooting errors. By default the logging level is set to WARN, for verbose logging, modify the C:\Program Files (x86)\Falcon Orchestrator\FalconOrchestrator.Client.exe.config file and set the logging level to DEBUG.
There is also a logger named API which will log the API stream detection events to disk in their raw JSON format. You will need to set the logging level for this logger to DEBUG as well to get the output written to disk. This can be useful if you need to verify the content from the API itself rather than what's stored within the Falcon Orchestrator database.