Security Information & Event Management platforms remain one of the most mis-sold, and mis-brought, information security products on the market. There are several reasons for this:
- People are hard to recruit, expensive to train and even more difficult to retain once you’ve trained them – as a result many SOC managers want to do as much as they can with technology in the belief that they’ll need less staff;
- Many SOC Managers come from a technical background, where their focus has been on configuring a hardware or software platform – whether it’s an Intrusion Detection/Prevention System, data leak prevention, firewall or anti-virus solution. As a result they have a natural technology-bias.;
- SIEM is a competitive marketplace with logging solutions moving up and entering the enterprise space. While many of these solutions lack a solid correlation capability, their mantra is simplicity, ease-of-use and low cost to initially implement. Many of the enterprise SIEM vendors’ reactions has been to oversimplify the reality of running a SIEM effectively to compete with these new challengers; and
- Customers have budget to spend, they often don’t want to undertake the fundamental information security activities that are required to be successful with a SIEM platform – identifying critical assets and modelling the threats against those assets, they just want to buy more blinky-boxes. The benefits of investing in people and process improvements are hard to quantify to management, especially if you lack meaningful metrics and key performance indicators but more on that in another post, but if you have a physical server or appliance, you can bring the management team down and show them ‘the box that goes ping’.https://www.youtube.com/watch?v=arCITMfxvEc
As a result, many of the Request for Proposals we receive from our customers simply list a number of event sources and the Events Per Second (EPS) volume for each along with a request for an architecture and quote. This bottom-up approach leads to Use Cases that model’s the IT infrastructure of your organisation, but the tools, techniques and procedures of an attack.
Instead, a good security operations centre capability should start with the basics – what are you trying to protect and against what? This can normally be accomplished through looking at your organisation’s risk assessment and threat models, but alas, many times these are either woefully inadequate or missing which is why I normally choose to undertake a Use Case workshop.
Before I delve into the high-level details of what a Use Case workshop consists of, it’s worthwhile pointing out the other benefits of conducting this workshop: stakeholder buy-in.
We normally see SIEM installations start with the systems that the information security department have control over – typically at least firewalls, anti-virus and Intrusion Detection/Prevention Systems. While Intrusion Detection/Prevention Systems and anti-virus can provide some meaningful information, we live in a World where a significant proportion of data on-the-wire is encrypted and unless you’re breaking out the encryption protocols the utility of Network-based Intrusion Detection/Prevention Systems’ has significantly diminished. Likewise, motivated attackers are doing their research to find out which anti-malware solution you are using (maybe through the technologies listed on the profiles of your ex-employees on LinkedIn?) and maintain a list of what anti-malware solutions block what exploits by leveraging tools designed to be used by defenders such as VirusTotal.
The reality is that to build good, solid use cases that will stand the best chance of detecting the activities of malicious insiders and well-funded, skilled adversaries, you need more than firewalls, anti-virus and Intrusion Detection/Prevention Systems – you need network device, operating system, application, storage, identity & access management, Virtual Private Network and even physical entry systems and to get these logs you need the buy-in of the Information Technology Operations group of your organisation. Collecting logs from these systems may have an operational impact on performance, while configuring the logging and tuning will certainly have an element of manpower that will distract IT Ops from their day-to-day activities of keeping the business running. It is no surprise then when the security operations team turn-up with demands for logs that there may be resistance from IT Ops. Involving the IT Operations team in the Use Case workshop is the single most important step you can take to bring the IT Ops and InfoSec departments together – the IT Operations team will get a more realistic understanding of the threats your organisation faces; may come up with innovative ideas for detection, response and automating workflow; and, most importantly, will feel a sense of ownership of the solution.
So you now know that IT Operations should have a seat at the table – but what is a Use Case Workshop? The best place to start is, what is a Use Case? There are differing definitions for what a Use Case is, but I normally use a definition heavily influence by one of my old colleagues Anton Chuvakin (now at Gartner): a use case is a description of how to detect a risk to your organisation and investigate it. This is not simply a SIEM rule – it includes details of the risk you’re trying to mitigate; the log event sources required to detect that risk; the SIEM rule logic; and the workflow required to triage, prioritise and investigate the incident (plus contain, eradicate and recover if incident response is also the remit of the Security Operations Centre function).
I normally start a Use Case Workshop looking at the critical line-of-business applications in the organisation – what keeps the lights on and the money flooding in (or the troops, intelligence, communications and logistics directed at the mission objectives, in the case of military customers)? Sometimes you can rely on previous risk assessments or Business Impact Analysis from the business continuity plans, other times you need to start with the fundamentals because although the organisation I’m working with may be about to embark on a journey to build a Security Operations Centre costing potentially millions of Euros a year, they don’t know what they’re protecting in the organisation. It’s at this point I’ll normally involve C-level in understanding the criticality of business units and line-of-business at a high-level, the operational staff in each department naturally think that their business unit is the most critical ending up with a ‘protect everything, equally’ mentality. Once you’ve got some consensus on what priortisation of what you’re trying to protect, you need to break these line-of-business down into the technology (including data stores, networks, applications, encryption, access management, physical data centres), processes and people that make up that line-of-business. Simply focusing on the technology, often the natural reaction of those in information security departments who’ve come up the ranks from Intrusion Detection Systems or firewall administrators, will result in weak links in the protection of that line-of-business, you need to capture all the components required to keep it up-and-running. The inclusion of the business units themselves, and the IT Operations department, here is critical. Don’t expect them to be able to provide all of the needed information however, it will require a skilled member of the information security department guiding the conversation.
One of the other advantages to starting with the line-of-business comes when you build management reports, by modelling the line-of-business you can now start to build management reports that can align risk reporting with the core business functions, providing meaningful reporting on the impact of information security events on the ability of the organisation to conduct it’s business – the key to aligning information security with “the business”.
Once you know what makes up the end-to-end line-of-business, it’s time to start modelling the threats to the line-of-business. I typically start by looking at the threat actors themselves and what would their motivations be for attacking a particular line-of-business? By addressing the attack motivation question you can prioritise building use cases that address the behaviours of those most likely to target that particular line-of-business. There is a sort of iterative process of looking at both motivation and means for each different threat actor at this point:
Why would an insider attack an internal Human Resources system -To get the telephone number of a co-worker he/she is infatuated with? To get inside information ahead of pay rise negotiations? To give him/herself a payrise? To get the address of his manager so he can nail a dead cat to his door? However, why would a criminal gang look at access the Human Resources system – To get the banking information of all your employees? To look for dates that payroll is paid so they can target specific systems that have been compromised on that date? Understanding who’s attacking you and what they are trying to do answers the Who? and Why? questions, the next important one to answer is How?
Then looking at your line-of-business and all the components that form it, walk through different scenarios taking into consideration the intent and skills capability of the attacker. Answering the Who? and Why? questions first stops you spending days designing a use case that is typically beyond the capability of that particular threat actor or ones where the pay-back for the attacker wouldn’t be worth the effort for them to undertake – you’re trying to avoid being dragged down a metaphorical alley by “that guy” who in business continuity planning meetings wants to prepare a mitigation against alien invasion before a loss of power scenario. Remember at this stage you’re trying to prioritise Use Case development towards the most impactful/likely at this point in time. You can always leave the alien invasion scenario on the road map and address it later in detail after you’ve covered the more pressing issues – you want to lay the foundational bricks at this stage and come back and mortar the cracks in, plus many of the more complex and outlier use cases can normally leverage and reuse the content you’ve build for the more impactful/likely ones.
Modelling the How would analyse the attack methodology used by the adversary, typically across a kill-chain or attack-chain. Many people have heard of the Lockheed-Martin Cyber Kill Chain as it has been covered extensively after it was successfully used to thwart attacks by Advanced Persistent Threats, such as Operation Aurora. Personally I don’t use the Lockheed-Martin kill chain, not just because they’ve patented it, but because it lacks granularity and needs to be broken down further to be useful – and the Weaponisation (sorry, “Weaponization”) stage takes place typically in a location where it cannot be observed and doesn’t lend itself to being useful to intrusion analysis. The attack chain I use is based on 10 stages:
- Reconnaissance or suspicious traffic
- Exploitation/Policy Infraction
- Privilege Escalation
- Establish Persistence
- Command and Control
- Internal Reconnaissance
- Lateral Movement
- Data Extraction/Preparation
Now not all scenarios will include all stages, simple policy infractions such as browsing pornography from a work’s machine can be identified at stage 3, but if a user has escalated their privileges to work around a filter it may be detected at Stage 3 and Stage 4. The point in the attack chain is to assist with the modelling of the end-to-end attack in a scenario and identify which event sources could provide context to each stage. I used the ISF Information Risk Assessment Methodology (IRAM) to provide the wider risk assessment framework – such as adversary characterisation, business impact and control selection. The output of IRAM provides a good input into modelling the scenarios and event sources needed to establish the attack-chain.
Now you’ve established what event sources are available (from the controls section and system/application logging), what actions the threat actor will take in each scenario, you’ve got the foundations for building your Use Cases.
Normally we create a Use Case matrix that details all of the details you’ve gathered above, along with a Level of Effort estimation to implement the Use Case. This Level of Effort should involve any effort to develop custom connectors to retrieve/receive, normalise and forward events (using HP ArcSight FlexConnectors, for instance).
This can then be used to conjunction with the risk assessment to do a cost/benefit analysis on the Level of Effort to select which Use Cases would provide the greatest value to the organisation’s detection and investigation capability. At this point you can start to write the rules in the SIEM.
I’ll cover the effective triage and tuning of rules in another post at a later date.