Incidents and breaches. These are the two words a C-level manager doesn’t want to hear. They can mean a myriad of things to each person. The CEO will be worried about sales and reputation; the CFO worries about fines and operational impact; the CIO is probably anxious about keeping his or her job and the CISO will be trying to understand what went wrong.
What can be done to avoid these situations?
During the 2014 Gartner Security and Risk Management summit the concept and need for an ‘adaptive security architecture’ was introduced and discussed. This means using a combination of technologies (both hardware and software) that can predict and prevent incidents with products or processes that can ‘detect and respond to’ attacks that signature and rule-based products might otherwise miss.
When you combine that approach with a rules engine, machine learning and a human interface then you have the beginnings of (what might be called) a managed detection and response service.
SIM, SEM and SIEM
These three terms have been around for some time and can mean different things to different people. Each has a purpose, but each also has a limitation. Security information management (SIM) is often used for historical reporting and trend analysis. It’s often based on log collection and is designed to give near-time visibility to your network and infrastructure performance.
Security event management (SEM), on the other hand, implies that something (an ‘event’) has already happened and that something has gone wrong. In a console environment it would highlight, or red flag, the event that would then need to be followed up.
SIEM, as its name suggests, brings SIM and SEM together and aims to correlate log entry with events and vice-versa. By knowing what triggered an event by reviewing logs gives context for an event and should allow you to remediate and prevent future events.
However, events and alarms are only any good if someone does something with them. In the 2017 Cisco Annual Cybersecurity Report (conducted in over 13 countries with close to 3,000 responses), it was noted that security professionals are reasonably confident in the tools they have but are less sure that they are using them effectively.
Further worrying statistics from the report show that of the 93 per cent of respondents that experienced a security alert, 44 per cent were not investigated. This could be anything from a mistyped password to an infection, ransomware event or breach going unscrutinised. Of those events that are investigated, less than half are remediated, meaning that there are a lot of legitimate alerts out there that are investigated but then have nothing done.
Now, there are many reasons why genuine alerts don’t get remediated including lack of time, resource, knowledge or just acceptance being some of the more obvious ones. What about the impact of the events that aren’t even investigated? The report suggests that these events can have an impact on productivity, customer satisfaction, trust and confidence.
An unexpected outage might not be seen as a security event yet it will have an impact and should be thoroughly investigated. Thirty-five per cent of downtime due to a breach lasts for more than eight hours. How would that affect your business?
All this points to a need for managed detection and response (MDR).
Detection
The first part of MDR is detection. Prevention and protection, external activities, are usually based on the ‘known knowns’ or the ‘known unknowns’, but there are also the ‘unknown unknowns’ and zero-day threats. Dealing with these has traditionally been very difficult, time consuming and usually expensive. It is nearly impossible to protect yourself against all eventualities unless you spend vast amounts of money and invest heavily on infrastructure.
And what happens when the previously unknowns become known? If you have the right tools you are able to go back and look for signs of it. As an example, a user downloads a file which at the time is not classed as malicious, but is later detected as having a timed payload. How do you find out who has downloaded and installed the file?
User behaviour also needs to be considered. Is someone doing something different, opening files from a new location or at a different time? Are they trying to access things they shouldn’t have access to and how do you become aware of events like this? Detection is key.
SIEM vs MDR
SIEM
- 24 X 7 (staffing)
- Usually on-prem (CapEx and resource issues)
- Owned (CapEx)
- Managed (skills)
MDR
- 24 X 7 (service)
- Off-site (redundancy)
- Managed service (OpEx)
- Highly skilled engineers
- Highly scalable
Reaction
Ultimately a breach or incident may occur and it’s what businesses do, how they respond to such events and how quickly, that determines how damaging it is in the long run. Statistics say that prolonged events tend to have far reaching consequences to the extent that some companies go out of business.
Incident response plans, much like disaster recovery and business continuity plans, need to be written and tested. Tests should be done regularly and reviewed for effectiveness as practice makes perfect.
Tests can take many forms but should be realistic and cover off the areas of the business where risks are most likely to occur or have the biggest impact. There should also be a mechanism for tracking and reviewing any remedial actions.
Case management for an incident, breach or test may sound like an insignificant step, but it is one that is often overlooked and is where most problems occur or why there are repeat failures. This is just one part of the ‘response’ element on MDR.
The golden bullet?
The Cisco report also states that 65 per cent of businesses use six or more security products. At the same time, many of these products will be from different vendors and less than 45 per cent of organisations use fewer than five unique vendors.
The Holy Grail for many organisations is having that single pane of glass that shows them their security stance. Failing that, ensuring someone else has that level of visibility and can aggregate all your tools into a single dashboard.
MDR services have been offered by several companies for the past few years. They do the hard work and take the logs and events of various products and technologies, perform look ups against lists of known and unknown events and are able to provide real-time alerting. This is supported by a group of skilled engineers who can triage an incident, make changes and or recommendations and provide actionable intelligence about the incident back to your security teams. It is this actionable piece that adds real value and makes the service worth having.
And GDPR?
Every article written at the moment seems to need a reference to the forthcoming General Data Protection Regulation (GDPR). MDR is no different. One key part of the new regulation is reporting. You need to be able to identify a breach to be able to report it. MDR can be tied to data loss Prevention (DLP) tools and configured in exactly the same way so that actionable alerts are triggered on alarms enabling the reporting to be satisfied.
David King is technical director of a cyber security managed security service provider and completed an MSc in cyber security with the University of Northumbria in 2016. He’s been a member of the BCS since 2005.
