Looking at log files generated by IT infrastructure software is one of the less exciting parts of an IT administrator’s job, but those log files determine the health of the system and, significantly, offer valuable insights into anomalous activities. Such insights can help thwart a security breach and minimise an organisation’s exposure to targeted cyber attacks.
Depending on the maturity and size of an organisation’s security operations centre (SOC), one approach may be better suited than the other. IT security decision-makers also need to take into account the complexity involved in setting up and configuring these security systems and assess realistically whether the threat the organisation faces merits the implementation costs.
“SIEM grew out of the need to consolidate logs in different formats from across the network, including security event feeds from other equipment, such as intrusion detection systems [IDSs], firewalls and user endpoint software,” says Paddy Francis, chief technology officer (CTO) at Airbus CyberSecurity.
Along with collecting log files, says Francis, a SIEM also provides a means of manually searching and analysing the data, typically using data analytics to generate alerts, present different views of the data to a security analyst and provide reports to stakeholders.
Also, a SIEM will typically provide a capability allowing detection use cases to be developed, he says. These look for specific sequences of events that may indicate an ongoing attack and can provide some integration into ticketing and other related systems.
However, as Francis notes, a SIEM can generate thousands of events per second and attackers are becoming more sophisticated. “Some advanced persistent threat [APT] groups can now take control of a workstation and break out into the network in an average time of less than 20 minutes from a user clicking on a link in a phishing email, and the average for all groups is less than two hours,” he says.
This has led to the notion of the 1/10/60 challenge: the need to detect an attack within one minute, understand it in 10 minutes and contain it within 60 minutes, says Francis. However, even the very best SOC analysts will struggle to meet the 1/10/60 challenge using just a SIEM toolset, he points out.
This is where SOAR helps. In Gartner’s Market guide for security orchestration, automation and response solutions, the analyst firm states: “The most common use case mentioned by Gartner clients which are planning to implement, or who have already implemented, SOAR solutions, is automating the triage of suspected phishing emails reported by users. This is a classic example of a process that follows a repeatable process, dozens to hundreds of times per day, with the goal of determining whether the email (or its content) is malicious and requires a response. It is a process ripe for the application of automation.”
A SOAR system is designed to speed up the response to an attack by automating the incident detection and response process. It can integrate with the SIEM, ticketing system, detection technologies, firewalls and proxies, as well as with threat intelligence platforms, to automate the overall detection and response activity.
Security automation
For Francis, a security operations team will typically have a playbook, which details the decisions and actions to be taken, from detection to containment. This may suggest actions to be taken on detection of a suspicious event through escalation and possible responses. SOAR can automate this, he says, taking autonomous decisions that support the investigation, drawing in threat intelligence and presenting the results to the analyst with recommendations for further action.
SOAR is designed to speed up the response to an attack by automating the incident detection and response process
“The analyst can then select the appropriate action, which would be carried out automatically, or the whole process can be automated,” says Francis. “For example, the detection of a possible command and control transmission could be followed up in accordance with the playbook to gather relevant threat intelligence and information on which hosts are involved and other related transmissions.”
In this example, the analyst would then be notified and given the option to block the transmissions and isolate the hosts involved. Once selected, the actions would be carried out automatically, says Francis. Throughout the process, ticketing and collaboration tools would keep the team and relevant stakeholders informed and generate reports as required.
But where there is a need to implement automated actions based on detected events, or when a consistent playbook of responses that must execute the same way every time is required, Venables believes SOAR is becoming increasingly essential for the enterprise. For instance, if a machine suddenly starts communicating with a server in an unintended location (outside its usual patterns), Venables says a SOAR tool can isolate that machine from critical systems, or disable specific ports from communication, depending on the nature of the threat.
Automation also enables the SOC – which may not be very large – to focus on the remediation of actual incidents, or perform detailed analysis. As Venables points out, the inability to take a course of action to mitigate incidents in a timely manner can happen if the team does not have enough time to monitor every single alert and take action within the organisation’s required service levels.
“If SOAR tools are implemented correctly, they can pull information from multiple security platforms and tools operated by the organisation and can integrate threat intelligence platforms, SIEM systems, and user and entity behaviour analytics [UEBA] to automatically identify indicators of compromise [IoC] that might otherwise take a security operations centre analyst hours to identify,” he says.
By pulling in security information, organisations can respond and stop suspicious or malicious behaviour before a human detects something is happening, says Venables. “The level of automation in a fully integrated system also removes large numbers of false positives from analytics and responses, saving valuable analyst time.”
Yet for all the advantages of automation offered by SOAR, Venables believes SIEM still has its place in an organisation. “As well as capturing the event and log data required for SOAR input, the ability of SIEM tools to effortlessly process large amounts of data means they can be deployed in other business areas, including service desk ticketing metrics and forecasting, real-time key performance indicator [KPI] dashboards, and cross-platform compliance and risk reporting,” he says.
For example, it can be difficult for people to identify root causes or indicators of larger issues by triaging all tickets logged by a busy service desk. But, says Venables, “a strong SIEM system can quickly pick up trends, correlate with other data sources and provide clear evidence that something requires further attention”.
Investment decisions
Venables also recommends that investment decisions should be based on the wider organisation and the security processes already established within it. For example, the National Institute of Standards and Technology (NIST) cyber security framework, which is rapidly being adopted as the industry standard for benchmarking, divides cyber security protection into five constituent elements – identify, protect, detect, respond and recover.
“Based on current iterations, SIEM is better suited for measuring the effectiveness and efficiency of the identification and protection domains, while detect and respond capabilities are covered by SOAR,” he says.
In Venables’ experience, the activities and workload of the team in the SOC is another useful indicator when assessing what additional support is required. If most of their time is spent investigating or responding to alerts captured by the SIEM tool, Venables recommends that IT security decision-makers should consider deploying a SOAR tool.
“Based on current iterations, SIEM is better suited for measuring the effectiveness and efficiency of the identification and protection domains, while detect and respond capabilities are covered by SOAR” Tom Venables, Turnkey Consulting
On the other hand, he says: “If the team is struggling to capture meaningful events, there is too much data to process, the tools are producing an overwhelming number of false positives, or incident management processes are yet to be defined, then enhancing the SIEM and its log collection and event management processes might be a wiser investment.”
The authors of Gartner’s Market guide for security orchestration, automation and response solutions warn that the main obstacle to adopting a SOAR tool continues to be the lack, or low maturity, of processes and procedures in the security operations team.
Significant configuration
As Airbus’s Francis notes, a SOAR tool generally requires significant configuration. “Default configurations may provide a start, but playbooks and defined workflows must be tuned to automate them in a SOAR solution because it will not generate these for you,” he says.
“Also, in order to respond, the SOAR tool must know how to reconfigure firewalls, DNS servers and proxies, for example, as well as isolating hosts in your specific environment. In the long run, though, SOAR will allow more to be done faster with less analyst input.”
With any IT security purchase, success will be determined by an organisation’s analysis of its current environment and its understanding of the threat and risk landscape. Venables urges IT security professionals to weigh up the advantages and disadvantages of automation versus manual processing and decide the value placed on each of the two stages.
“Appreciation of the specific requirements guards against spending on capabilities that are not needed,” he says. “Separate ‘best fit’ systems can also be selected, resulting in an advanced solution in each area, rather than a single-supplier model which potentially compromises on functionality.”
