The University of Exeter - Part 2: "Zero to SIEM" in 8 weeks, the Splunk Deployment
04/09/19 – Author: Baz Donaghue – Certified Splunk Consultant at Somerford Associates
The first and subsequent steps on any organisations IT Security journey can be difficult and uncertain at the best of times. To go from little or no security use cases and consolidated view of your security landscape, to a fully implemented SIEM solution is a challenging undertaking. Throw into the mix a compressed timeframe for planning and implementation, this makes an already precarious task all the more formidable.
This is exactly what University of Exeter (UoE) did with their Splunk Enterprise Security Implementation, along with expert support and services provided by Somerford Associates.
Picking up where we left off from the previous blog, we will be exploring how the above was achieved utilising security use case planning and “user stories”.
Making it happen: Plan.
- In order for any security operations team to be effective, they need to have a clear understanding of the threat landscape of their organisation. This can often be a daunting task if no such analysis has been carried out especially if you factor in the many unknowns further education and higher learning facilities have to contend with such as students bring their own devices to access networks, internet facing learning and personnel management tools as well as a multitude of productivity and collaboration platforms.
- To turn a SOC and it’s team from carrying out ad-hoc, reactionary operations to repeatable and later proactive activities, planning of security use cases and building playbooks detailing the incident response process is key. There are two principal approaches to this stream of work that UoE and Somerford took to put these use cases in place and immediately begin profiting from the value Splunk brings to any security team:
- Organisationally driven use case planning
- Data source analysis and mapping.
Use case planning: map it out!
- One challenge we see many of our customers face is that of deciding which use cases are relevant and how these map against the organisation.
- One method of understanding the art of the possible is to utilise “Splunk Security Essentials” (SSE)
- SSE is a free application from Splunk that provides example security use cases of varying degrees of maturity.
- Each use case highlights the type of security event it aims to detect, the data sources involved and recommendations on next actions and possible false positives.
- These use cases are a fantastic starting point to then develop further and tune to your specific organisation.
- Whilst SSE makes it very easy to identify potential use cases to use within our environments, when building a SIEM capability at pace simply using the examples available is not sufficient. Instead, we must take these examples and tune them to match our security requirements and data sources, and to effectively do that, we can build a “user story”!
- A user story is an end-to-end exploration and documentation of a use case, detailing all potential “contact points’ with the various technologies within our environments. Let’s have a look at an example, but before we do we need to choose a use case:
- We can see from the above that it uses web or proxy tagged data as well as some possible well known sourcetypes to build a table of events that feature a “bytes_out” field greater than 35000000 (35Mb). Now we understand the data sources and expected fields we can map out user story:
- Let’s explore a few of the questions now:
- Question: Are the proxy usernames and system usernames the same?
The outcome of this question may well inform us of the requirement to capture both sets of logs. For example, if the proxy usernames and AD usernames are the same, then we may not require the AD events as we will capture all the fields we need in the proxy events, however if they are different and potentially unattributable (for example if the proxy used the convention “proxy_user_1, proxy_user_2” etc.) then we might need both logs in order to correlate and enrich the username field. - Question: Does the web proxy monitor and block large web uploads?
Seems simple enough a question but the outcome can greatly change the effort required to monitor for this use case. For example, if the proxy is already mitigating the security use case we are looking to monitor with Splunk, do we need to use Splunk to detect this event? We could simply configure the proxy to report on when this rule is violated, using the proxy to do the heavy lifting and just monitor the proxy log. Alternatively, if the answer is no then we will need all the relevant data to ensure that this type of security incident is effectively monitored from within Splunk and that we have the data to be able to do this.
- Question: Are the proxy usernames and system usernames the same?
In part 3 we will explore how the next steps needed to foster a culture of Rationalise, Rectify and Reassess, and an explanation of how data source analysis can help us leverage additional value from the data we already have.
