SOC Mistake #7: On Use Cases, You Model Your Defences, Not Your Attackers
Use Cases – these are simply the most misunderstood subject around both security operations and Security Information & Event Management (SIEM).
SIEM is one of the most mis-sold and mis-brought items of information security technology. The most common type of Request For Information we get from customers lists the different types of event sources and the Events Per Second (EPS) for each event source. The customer often believes that a SIEM is magical, that it understands everything about their business and their threats. All they need to do is merely pump their raw events into and actionable security intelligence pops out of the other end.
This means that procurement of SIEM is largely down to whether the SIEM supports the event source and whether the architecture supports the event volume. This technical bias when purchasing a SIEM means that Request For Information rarely looks at the operational processes in actually using a SIEM, and therefore the effectiveness and efficiency of the SIEM.
This approach ends up aligning with the defensive infrastructure of the organisation, rather than trying to detect the behaviour of an attackers. The SIEM will typically provide you details of a correlated event or anomaly which is the starting point, not that end point of intrusion analysis – if you SOC staff are simply escalating alerts to the CERT, they are simply acting as ‘click monkeys’ and not providing any value to the intrusion detection/investigation/response capability. The more accurate the modelling of the method of attack and additional context the SIEM has around the user, assets and know attacks and attacker behaviour: the more the technology is doing the heavy lifting.
Ideally what you are looking to achieve is something along the lines of:
Level 1: elimination of false positives; prioritisation based on the criticality or sensitivity of the assets involved in the case; initial investigation of the incident to answer the When? Who? How? What? Why? questions before escalation (if required) to the next level for more specialist investigation.
Level 2: more detailed investigation of the incident, which may involve escalation to the Incident Response Team (IRT) and then an interactive process of the Level 2 Analyst providing details of compromised systems and suspicious users to the Incident Response Team who will perform more detailed forensic analysis, that may result in one-or-more additional Indicators-of-Compromise (IoC) that the Incident Response Team will pass back to the Level 2 Analyst to conduct searches using the log management platform and SIEM to identify additional systems or users involved in the incident that can then be passed back to the Incident Response Team. The aim is to allow the SOC to specialise in technical skills required in log analysis and SIEM, and the Incident Response Team in network and host forensics.
When you consider the whole point of a SIEM Use Case is to drive the detection of the attack through correlation or anomaly detection rules in the SIEM platform, to detect incidents through post event analytics and to drive the intrusion analysis process to answer the core questions:
When? When did this attack start? Is it a stand alone action, or is it a part of a wide campaign or a stage in a broader attack? If it still ongoing? Is it better to escalate immediately and kick off the containment and eradication, or to observe with your finger over the trigger to gain more information around intent and capabilities? With actors that would be typically classified as Advanced Persistent Threats (APTs), rather like the boy with his finger in the dyke, responding to the symptom and closing off one vulnerability will simply mean they’ll try again and come back through another avenue. Gaining a better understanding of the capabilities, tools and ultimate intent of the attacker will help you ensure that your preventative controls will be optimised to prevent future attacks from that threat actor.
Who? Attack attribution is always challenging, just because you can geo-locate an attacker’s IP adjust doesn’t mean that’s the source of the attack – they can be pivoting through other compromised hosts and networks, or they could be utilising some form of anonymising network, such as The Onion Router (TOR). Was this an external party, an insider or someone from your supply chain? If an internal party is involved, it is sometime necessary to increase the priority of the incident, due to the internal knowledge of assets and provisioned access to internal resources exponentially increasing the potential expediency of attack execution and likelihood of success. Threat Intelligence can be used to profile the Tools, Techniques & Procedures (TTPs) that specific groups use and this can be compared to what you are seeing – again, the decision to continue to observe, or immediately escalate can be driven by the potential impact on the business of continuing to allow the threat actor access to your resources, compared with the benefit of gaining greater accuracy in attribution and confidence in understanding their capabilities.
How? Intrusion analysis should allow you to build a timeline of the attack. For instance, which users (if any) were involved? Which systems were compromised? What data was accessed? Again, this timeline can be compared with Threat Intelligence to identify a potential modus operandi that can be used to attribute the attack to a particular group, which will give additional insight into intent and motivation.
What? What assets have been compromised? What data has been accessed?
Why? This is ultimately the most difficult question to answer. What was the ultimate intent of the attacker? As I’ve mentioned previously, if you can utilise known TTPs to attribute the attack to a specific group, you can look at what the outcome and intent of other attacks by that group was and use this to inform why they would be attacking your organisation. Otherwise you may have to guess based on what you’re seeing in the attack, such as the nature of the assets they are accessing. The decision to continue to observe rather than immediately contain/eradicate should be taken based on the potential risk, but the use of tools such as honeypots and tarpits can allow your analysts to observe behaviour without risk to live production systems and data.
Even in those organisations that do drive their Use Cases from attempting to model an attack, they often have a tendency to gravitate towards using logs such as firewall, anti-virus and Intrusion Detection/Prevention Systems (IDS/IPS). Why is this? Well that because these logs are typically from devices that are owned and configured by the Information Security Engineering team, rather than IT Operations. In many organisations the relationship between IT Operations, whose main focus is on continuity and performance of services, and Information Security, whose focus on the security of data, can be challenging.
Logs from firewall, anti-virus and IDS/IPS systems are becoming increasing less relevant in modern attacks. Attackers today will attempt to make their initial exploitation attempts, command & control and exfiltration look as much like normal day-to-day traffic as possible – the traditional ACCEPT/DENY rules of a firewall based on IP address and port of source and destination just doesn’t cut-the-mustard anymore. Even ‘next generation’ firewalls cannot provide the level of visibility in encrypted packets over Secure Sockets Layer (SSL) for instance. Just like next generation firewalls, IDS/IPS cannot look for signatures of known attacks on networks where the traffic is encrypted by technologies such as Secure Sockets Layer (SSL) without the break-out of the encryption. Finally, traditional anti-virus solutions have been notorious for not stopping modern attacks. It’s fairly simple to look at the vendor’s names listed technical skills of current and ex-employees of your organisation on LinkedIn. Then it’s just a case of finding an exploit that the vendor’s product can’t find using a resource like VirusTotal and you’ve got your in.
