Risk Analysis With Enterprise Security 3.1

    The Risk Analysis Framework was introduced as a new feature in Splunk App for Enterprise Security 3.1, and provides users with the ability to utilize a risk scoring system for assigning varying levels of risk to a multitude of different assets and identities.

    In the context of the Risk Analysis Framework- assets, identities, and anything else you would consider assigning a risk score to, is referred to as a Risk Object. Risk Objects are categorized under different Risk Object Types. For example, if ‘brians_laptop’ was our Risk Object it would be categorized under the ‘system’ Risk Object Type. Out of the box, Enterprise Security 3.1 comes configured with 3 different risk object types: ‘system’ for assigning risk to assets, ‘user’ for assigning risk to identities, and ‘other’ for assigning risk to any other type of data that wouldn’t be considered an asset or identity. Some examples of risk objects that would fall into the ‘other’ category would be things like the explicit name of a process, or physical location that in of itself carries an elevated risk.

    Though it’s encouraged that users follow the Risk Scoring guide found below, any arbitrary number, positive or negative, could be used. This provides a flexible framework that enables users to define a level of Risk that fits their IT administrations standard operating procedure.


    Lets walk through how we can use the Risk Scoring Framework to help assess and monitor the overall risk impact of a malicious event that affects, not just one or two assets, but a sizeable number of assets globally throughout an IT ecosystem.

The Story

    We’ve just come into work and are notified of a spear-phishing campaign that has been launched against our enterprise. We know a spear-phishing campaign entices the email recipient to run a malicious attachment or click a link that directs the victim to malicious code. If the endpoint is vulnerable and an unsuspecting recipient clicks on the link or executes the attachment, the machine will become infected and the attacker will establish a foothold within the environment. Leveraging this foothold, the attacker will then have the means to move laterally throughout the environment and begin staging mission critical data for exfiltration. We’re told that the email is disguised to look as though it came from our IT department and encourages users to perform a critical update to their systems. The email is as follows:


    We know the email was accepted for delivery by our SMTP gateway for a large number of user accounts; however, we are unaware of the number of users that clicked and downloaded the .zip file or the number of compromised systems. Note, even though a user clicks and downloads the file, the system might not be compromised. Lets assume for a moment that our analysts have already taken proper measures to begin analysis of the threat, as indicated by their standard operating procedure. That having been done, we would now like to utilize the new Risk Analysis Framework included with Enterprise Security 3.1 to help us monitor and assess the risk this threat represents to our enterprise as a whole.

    The first thing we need to do is break the threat down into its various stages, so it can be isolated. For simplicity, we will focus on the endpoint, with 3 stages – link is clicked, malicious file deposited on the endpoint, malicious file executed and communicating to its command and control (C2) server. We then assign risk scores contingent on the level of risk each stage represents to our enterprise. The scenario is illustrated in the following stages and assigned risk scores consistent with the guide found above.


    Now that we’ve broken down the threat, we can create correlation searches that utilize logs from affected endpoints or intermediary network appliances, to not only alert us to when a specific stage occurs, but also provide quantifiable metrics that can be used to assess the overall risk of each stage. We do this via the Configure – General – Custom Searches menu item, clicking the “New” button in the top left of the page you’re directed to, and selecting “Correlation Search” from the dialogue that pops up.


    After defining our new correlation searches and setting up the parameters for our notable event, we are given the option of indicating whether we would like a risk modifier created. Because we want to create one, we check the “Create risk modifier” box. This displays a number of required fields that need to be defined. The first of which is a Risk Score. This can be determined, again, by referencing the guide above, or by way of your standard operating procedures. Next, we need to define a Risk Object to apply the score to. We do this by indicating which field contains our risk object. And lastly, we need to specify the Rick Object Type from within the drop down.


    In addition to providing static values for our Risk Score and Risk Object fields, we could also set these fields dynamically based on the results of our search. This is more of an advanced feature and a bit outside the scope of this blog post. But, if you’re interested in learning more of the advanced features of the framework please indicate so in the comments below.

    Returning to our story, we’ve just setup our correlation searches and configured them to apply risk scores to any affected assets. In doing this, it’s important to note that although our searches generate notable events AND apply risk modifiers, we don’t have to do both. Correlation searches can be setup such that they only apply Risk Modifiers. This provides users with a means of tracking events that alone may not justify the creation of a notable event, but in combination with other events, may warrant further review. Now that our searches are configured, we can now use the Risk Analysis Dashboard to get an overall view of the impact the spear-phishing campaign has had on our corporate risk posture.


    The Risk Analysis dashboard gives us an aggregated overview of risk associated with the spear-phishing campaign. It timelines the impact of the campaign by summarizing the first and last occurrences of the events within the “Risk Modifiers Over Time” panel. The “Risk Score By Object” panel tells us which assets were impacted most severely by the campaign by way of displaying a total aggregated risk score for each asset in descending order from highest to lowest.

    The “Most Active Sources” panel gives us a glimpse into the total amount of risk distributed as a result of a specified stage within the compromise. And the “Recent Risk Modifiers” panel displays the most recent indicators that have resulted in the assignment of a risk score.

    It’s also important to note that if at any time, while reviewing this data, we feel the need to dig deeper into the Risk Scores applied to any individual asset or identity, we can quickly do so using the user input fields at the top of the dashboard.



    To recap, we started with a need to monitor the growing level of risk that a recent spear-phishing campaign had on our enterprise while we underwent remediation of the threat. To do this, we broke the threat down into three different stages and applied risk scores to them based on our provided risk-scoring guide. Once the threat levels were defined, we then created correlation searches that applied risk scores to any assets that executed one of our defined stages. We then leveraged the “Risk Analysis” dashboard to get an overall view of the impact the spear-phishing campaign had on our corporate risk posture.

    When you expand the idea of monitoring the risk one threat represents to your environment to leveraging the Risk Analysis Framework to monitor tens, hundreds, even thousands of threats, you can really start to visualize the bulk of what the framework has to offer. It’s a centralized source for monitoring aggregated risk scores, assigned by a multitude of different threats, from internal to remote, across your entire corporate enterprise. In addition, the flexibility of the framework allows users to diversify their asset and identity groups such that higher priorities can be placed on those that have a more critical business impact if compromised. It’s an all-inclusive package for monitoring the Risk Posture of even the most diverse IT environments.


Brian Luger

Posted by