The standard requirements needed to run the SafeTitan Orchestrator and Management console on premise are listed below:
|Operating System||Windows Server 2008 R2 (or higher)||Will also run on any 64 bit Windows OS from Windows 7 and higher.|
|Operating System Architecture||x64||Currently Supporting 64 bit.|
|RAM||16GB||Inclusive of running IIS and basic Server components.|
|Hard Drive||8GB Free Space||The applications are relatively small. However a little extra storage is recommended for Logging.|
|Application Server||IIS 7 or Higher|
Aside from the technical requirements documented above, Real Time will need to integrate with a SIEM technology. Listed below are the currently supported applications.
- MS Sentinel
- DTEX Agents
On-Premise components overview
Cyber Risk Aware’s RealTime Response Orchestration process is comprised of three main components. The Orchestrator, the Orchestration Manager and a supported Network monitoring technology such as a SIEM
monitoring technology such as a SIEM, DLP, Web Gateway.
The Orchestrator comes in two flavors, On-Premise and Cloud. For the purposes of this article, we will be discussing the On-Premise installation. Details on the Cloud Orchestrator can be found here. The on-premise Orchestrator is a small web application that is hosted on Premise. This Application receives the events of interest from supported Network monitoring technologies such as a SIEM and forwards the captured event information onto the appropriate endpoints in the Cyber Risk Aware cloud platform. Events of interest are configured within the SIEM / Network monitoring tool implementation (such as removable storage being detected or malicious software being downloaded). The information passed to the Cyber Risk Aware cloud is minimal. It is only an identifier for the event (such as the rule name) and an identifier for the user that triggered the event (such as the AD Username). Information such as passwords etc. are not captured.
When a SIEM / Monitoring tool alarm is triggered, the username of the user that triggered the alarm is passed to the Orchestrator. The Orchestrator uses this username to lookup Active Directory for the user and gathers metadata such as the identifier that is used to uniquely identify the user in Cyber Risk Aware (the user's email/username on the Cyber Risk Aware portal). Other metadata can also be optionally pulled from Active Directory such as:
- The users Skype for Business Username (SIP)
- The users SLACK username
These optional properties are required only if the Organisation wishes for Real Time Responses to be sent to the users by IM.
You can, if needed deploy multiple Orchestrators. This can be useful in Organisations' with Multi-Forrest setups.
Similar to the Orchestrator, the Orchestration Manager is a small web application hosted on-premise (on the same server as the Orchestrator). The Orchestrator Manger contains a web interface that can be used to start and stop the Orchestrator Site. It can also be used to view its current status (running, stopped etc.). The main job of the Orchestration Manager however is to manage the installation of updates for the Orchestrator.
From time to time updates will become available for the Orchestrator. These updates could contain new functionality or simple bug fixes. The Orchestrator Manager's web interface will show that updates are available and provide the ability for the latest updates to be downloaded and applied. The downloads will simply be a Zip containing the new version of the Orchestrator.
Configuration changes can also be made to the Orchestrator via the Orchestration Manager's user interface.
As mentioned above, an Organisation can have multiple Orchestrators. If this is the case, they will also require an Orchestration Manager for each Orchestrator instance.
Supported SIEM / Network Monitoring Application
In order for a Network monitoring application to communicate with the Orchestrator, it must make use of an appropriate web-hook exposed by the Orchestrator. Depending on the chosen technology, the integration with the web-hook will be different.
LogRhythm alarms can be created to be triggered based on specific criteria such as a Domain Account being created on a Removable storage device being detected. When this alarm triggers, the information must be passed the Orchestrator. In order for LogRhythm to make use of the web hook, it makes use of a Feature called a Smart Response. The Smart Response basically allows us to define a PowerShell script that accepts a collection of parameters passed from the alarm instance. The PowerShell script will in turn pass this information to the Orchestrator. We will look at the Smart Response configuration a little further into the document.
Splunk Enterprise Security (ES) is a security information and event management (SIEM) solution. Alarms created in Splunk can be configured to forward data to a Web hook when the alarm has been triggered. The Web hook should be configured to forward information to the Orchestrator. Configuring the Web hook in a Splunk alarm is discussed later in the document.
Currently support for Splunk and LogRhythm is implemented and ready to use. Solutions for other technologies (such as Logpoint, MS Sentinel & DTEX Agents) are also available but may need some customization's from Cyber Risk Aware. These customization's or functionality extensions would typically have a turnaround time of 1-2 weeks and would require collaboration with technical / network team on the Organisations side.
The diagram below illustrates a high level Architecture of the Cyber Risk Aware Real Time Response process for on prem Installation. We also support cloud deployments.
.NET Core Hosting Bundle for IIS
Both the Orchestrator and Orchestration Manager where developed using .NET Core. This allows both applications to be deployed as ‘Self-Contained’. This means that the will not have a reliance on a specific version of the .NET CORE run-time in order to work. This is beneficial when updating the applications as it means the infrastructure that hosts these apps will not need updated (no need to install newer versions of .net framework) as the applications evolve via the updates. A minimal version of the run-time is deployed with each application.
In the initial setup however, IIS will need the ASP.NET CORE Module installed in order to host the two applications.
Note: If the server does not have an internet connection, the Microsoft Visual C++ Redistributable will need installed before installing the Hosting Bundle. This redistributable can be found here.
To install the .NET Core Hosting Bundle, click on this link and scroll to the ‘Windows’ section. Here, select the link for ‘Hosting Bundle Installer’.
Once the install has completed, either restart the System or execute net stop was /y followed by net start w3svc from a command prompt. Restarting IIS picks up a change to the system PATH made by the installer.
Both the Orchestrator and Orchestration Manager will require sites configured in IIS.
Configuring the Application Pools
Both sites will require Application Pools Created in IIS.
Orchestrator Application Pool
As mentioned earlier in this guide, the Orchestrator needs to communicate with Active Directory to lookup information on the user that triggered an alarm. This is only information required to be able to contact the user (Email, Skype Username etc). Due to this, the Orchestrator application will require 'Read' access to the Organisations Active Directory. This is the minimum permission required.
To achieve this, the Orchestrator's application pool must be run as a user with this level of access, such as the domain controller.
To create the Application Pool for the Orchestrator, open IIS, right click on the Applications Pools node, and select Add Application Pool.
In the resulting dialog, ensure the details match the following:
Once the application pool is created, right click on it and select Advanced Settings. This will open a new dialog. Here, scroll to the setting Identity and click the button as shown below.
In the resulting dialog, we can select Custom Account and click the Set button.
In the next dialog, enter the credentials for the privileged user that the Orchestrator will be running as (A user with Active Directory Read access). Complete the process by clicking OK on each of the dialog.
Orchestration Manager Application Pool
The Orchestration Manager needs permission to start and stop the Orchestrator Site on IIS. (It will not stop IIS itself, so no other sites on the same IIS instance will be affected).
To allow the Orchestration Manger this permission, we can give NETWORK SERVICE permission to Read the file: “%windir%\System32\inetsrv\Config\ redirection.config”
Do this by right clicking on the file, selecting Properties and then the Security tab. From here, click on the Edit button.
Upon clicking Edit the following dialog is presented:
Click Add. Enter NETWORK SERVICE into the text area in the next dialog and click Check Names.
Click OK and when returned to the next screen, ensure the NETWORK SERVICE has Read permission ticked.
Click Apply and then OK to complete the process.
Finally, the Application Pool can be created with the following setup:
In the Advanced Settings for the Application Pool, ensure the Identity property is set to NETWORK SERVICE.
Both the Orchestrator and Orchestration Manager communicate via a secure HTTPS connection. As such a Certificate must be associated with the sites. You can use either an
existing certificate or create a new certificate. A self signed certificate can be used, but it is advisable that the certificate is signed and imported by a third party.
For the purposes of this guide, we have generated a Self-Signed Certificate and named it SafeTitanCert. This Certificate will be used for other the Orchestrator and Orchestration Manager sites.
Set Up the Orchestration Management Site
To create the Orchestration Manager Site, a folder must be created to house the deployed application files. Create a folder on the Server called ‘OrchestrationManager’ (e.g. c:\cra-apps\OrchestrationManager).
With the folder structure created, the site can be added. Open IIS and expand the Sites node. Select Add Website...
In the resulting dialog set the following:
Site Name : OrchestrationManager
Application Pool : OrcherstrationManagerAppPool
Physical Path : <Patch to previously create OrchestrationManager folder>
Binding Type: Https
IP address: <Any unassigned address>.
Port: <Any unassigned port>
Host: <Leave Blank>
SSL Certificate: <Name of the certificate>
This will result in a set-up similar to the following:
Set Up the Orchestrator Site
Similar to the previous step, the deployment folder must first be created. Create a folder on the Server called Orchestrator (e.g. c:\cra-apps\orchestrator).
Open IIS and expand the Sites node. Select Add Website...
In the resulting dialog set the following:
Site Name : Orchestrator
Application Pool : OrchestratorAppPool
Physical Path : <Patch to previously create Orchestrator folder>
Binding Type: Https
IP address: <Any unassigned address>.
Port: <Any unassigned port>
Host: <Leave Blank>
SSL Certificate: <Name of the certificate>
This will result in a set-up like the following:
Install Orchestration Manager
Next, the Orchestration Manager files need to be deployed.
The package for installing the Orchestration Manager can be downloaded from your Cyber Risk Aware portal.
Log in to your portal and navigate to Real-Time integrations -> Orchestrator Settings
At the top of the page that is displayed to the right of the navigation menu, you can download a new Orchestration Manager package by clicking the button Generate Orchestration Package.
You will notice two things upon clicking the Generate Orchestration Package button.
- A download will begin of the OrchestrationManager.zip. This will contain the package needed to install the Orchestration Manager.
- A new entry will be added to the Orchestrator List grid. This will be the generated default configuration for the Orchestrator that you will be installing. It should appear similar to below. We will come back to this later in the setup.
With the OrchestrationManager.zip that has been downloaded, extract the contents to the OrchestrationManager folder we previously created I.E c:\cra-apps\OrchestrationManager.
The next thing we will need to do is update the config file included in the Orchestration Managers installation folder I.E: c:\cra-apps\OrchestrationManager\appsettings.json. The appsettings.json file requires two properties populated.
- OrgId: This is a unique identifier for the Organisation. This can be found to the right of the Generate Orchestration Package button, labeled Global Organisation ID.
2. OrchestratorId: This is the unique identifier for the Orchestrator you are installing. This value is displayed in the grid directly after clicking the button to generate the
The resulting config should look similar to the following:
Save changes to the config file.
This should complete the installation of the Orchestration Manager. If you now browse to the site created (in this example you created the site on port 443 of localhost), you should see the Management Portal’s web interface.
You can see from the portal that the Orchestrator site is not yet running. We will move onto that next.
Basic Orchestration Manager Configuration
Some of the basic / required settings for the Orchestration Manager must be configured before we can install the Orchestrator itself.
The Orchestrator settings can be edited via your Cyber Risk Aware portal (the entry that was generated in the Orchestrator List grid above.
To edit the Orchestrator settings, navigate to your Cyber Risk Aware portal and to the Orchestrator Settings menu:
In the grid, select the edit button next to the Orchestrator you wish to edit. The screen below will be displayed:
We will discuss only the properties required at this stage of the installation.
Some of the properties here will come pre-populated. Pre-populated properties should not need changed in a standard installation. The properties listed below are required at this stage of the installation:
Name: This is the label you wish to give the Orchestrator. This can be a useful identifier in a multi-orchestrator setup.
Runtime ID: This is pre-populated and is used to determine which build of the Orchestrator is required. It should not need changed unless running on a server other than 64bit Windows.
Local Storage Location: This will need to be set to a folder on the Server that will temporarily store the latest updates as they are downloaded. The Orchestration Manager will clean this folder up after use.
Orchestrator Site Location: This should be the full path to (and including the folder) where the Orchestrator is to be installed. This should match the folder used for the site in IIS (e.g c:\cra-apps\orchestrator).
Event Grid endpoint: This is a pre-populated field containing the endpoint used by the Orchestrator to forward events to Cyber Risk Aware cloud platform.
Event Grid Shared Access Signature: This is a pre-populated field that is used to authenticate connections to the Event Grid endpoint.
Version: This is a read-only field used to indicate the version of the Orchestrator that is running.
To save the changes here, click Save.
The Orchestrator is managed entirely by the Orchestration Manager. We should use this to install the latest version of the Orchestrator. In order for the Orchestration Manger to know where to install the Orchestrator on the Server, ensure the Orchestration Manager property Orchestrator Site Location mentioned in the previous section is populated correctly with the location we wish to deploy the Orchestrator Site.
Navigate to the Landing page for the Orchestration Manager. From the landing page, click the hyperlink Click here to update now.
You will be presented with the following dialog that will output the progress of the installation:
This process should run to completion and inform you that the Orchestrator as installed and we are using the latest version.
Clicking close will take us back to the landing page, and we can see that the Orchestrator is running on as the latest version.
To verify this process, navigate the Orchestrator's website URL as we defined in IIS (In out installation we set this to localhost:444):
Configuration File Updates
In order for Cyber Risk Aware to be able to identify the Orchestrator and the Organisation that are making the requests, the IDs' of the Organisation and the Orchestrator must be included in the Orchestrator's configuration file. I.E c:\cra-apps\Orchestrator\appsettings.json.
Orchestrator Configuration File
Open the directory that you have the Orchestrator installed I.E c:\cra-apps\Orchestrator. In this folder, open the file named appsettings.json In this file exists properties similar to the Orchestration Managers configuration, called OrgId and OrchestratorId which will be blank. Populate this with the Ids found in the Orchestrator Settings page on the portal.
The OrgId can be found next to the label Global Organisation Id:
The OrchestratorId is located in the grid next to your generated orchestration package:
The resulting configuration will be similar to the following:
Save and confirm changes.
Both sites will need restarted in IIS before they take affect.
Active Directory Integration
With both the Orchestrator and Orchestration Manager set up. The last configuration item for the Orchestrator to be able to receive and parse messages, is to inform the Orchestrator of which LDAP to use and which attribute within the LDAP it should use to get the Cyber Risk Aware username. This is typically the users email (which would be the mail attribute, but can be any attribute supported by LDAP).
Navigate to the Cyber Risk Aware portal in your browser and select to edit the settings of the Orchestrator. The properties we are interested in editing here are LDAP and AD Identifier.
In the example above, our LDAP is set to the full LDAP URL. The AD Identifier is set to the Active Directory Email property.
Below is a full list of mappings between the Active Directory labeled fields and the LDAP attributes.
|Label in AD||LDAP Attribute|
|Middle Name / Initials||initials|
|Logon Name (Pre Windows 2000)||sAMAccountName|
|Country 2 Digit Code - eg. US||c|
|Country code -eg. for US country code is 840||countryCode|
|Account Expires (use same date format as server)||accountExpires|
|User Account Control||userAccountControl|
|User Photo||thumbnailPhoto / exchangePhoto (Supports high resolution photo) / jpegPhoto / photo / thumbnailLogo|
|Log on to||userWorkstations|
|Simple Display Name||displayNamePrintable|
|Hide from Exchange address lists||msExchHideFromAddressLists|
|Sending Message Size (KB)||submissionContLength|
|Receiving Message Size (KB)||delivContLength|
|Accept messages from Authenticated Users only||msExchRequireAuthToSendTo|
|Reject Messages From||unauthOrig|
|Accept Messages From||authOrig|
|Send on Behalf||publicDelegates|
|Deliver and Redirect||deliverAndRedirect|
|Use mailbox store defaults||mDBuseDefaults|
|Outlook Mobile Access||msExchOmaAdminWirelessEnable|
|Outlook Web Access||protocolSettings|
|Allow Terminal Server Logon||tsAllowLogon|
|Terminal Services Profile Path||tsProfilePath|
|Terminal Services Home Directory||tsHomeDir|
|Terminal Services Home Drive||tsHomeDirDrive|
|Start the following program at logon||tsInheritInitialProgram|
|Starting Program file name||tsIntialProgram|
|Connect client drive at logon||tsDeviceClientDrives|
|Connect client printer at logon||tsDeviceClientPrinters|
|Default to main client printer||tsDeviceClientDefaultPrinter|
|End disconnected session||tsTimeOutSettingsDisConnections|
|Active Session limit||tsTimeOutSettingsConnections|
|Idle session limit||tsTimeOutSettingsIdle|
|When session limit reached or connection broken||tsBrokenTimeOutSettings|
|Protect accidental deletion||preventDeletion|
|Manager can update members||managerCanUpdateMembers|
|Primary Group ID||primaryGroupID|
|Exchange Server Name||msExchHomeServerName|
Once you have entered the value for AD Identifier. Click Save.
This concludes the Orchestrator and Orchestration Manager setup.
Next steps would to now begin integration with your chosen SIEM / Network monitoring application. There is a separate document for each applications integration set up.