It is hard to soar with the eagles when you work with turkeys was a saying we used to use in the army. In the realm of security, this has never been a truer set of words spoken.
Protecting IT infrastructure and applications is hard. It does not help that historically the Security department has been seen as the department that ”put the no into innovation”, but the obverse is also true, the security team view Developers, Operations, project delivery teams, and even end-users as the enemy and often treat them as such; thereby alienating a good ally in building a secure platform. That said the later also seen the Security team as the weird one nobody wants to invite to their party – so it is a two-way street.
Traditional Security has been seen as blocking improvement programs, primarily because of a lack of knowledge of the new environment or platform functions, features, and footprint. To be fair on the security teams here, the vendors of those platforms do not make it easy for a security team to do a valid risk assessment on their products. There is a distinct lack of overt security information on many vendors’ sites and their sales teams, both commercial and engineering are trained on features, not potential weaknesses; this is a gap in the vendor’s armory. It is to be expected: they sell to their strengths and avoid questions about perceived weaknesses.
However, for the vast majority of corporate end-users; both enterprise and SME’s, a well-staffed and capable security team is a pipe-dream, and having one that is capable of having the time to fully risk assessment new products for security posture is beyond even that.
Now, what if I said there was a solution?
The rise of DevOps and Automation in the technical workplace and the increasing sophistication of hostile threats have forced the security teams to look at new methods of keeping the environment secure. Spending days reviewing log printouts from multiple sources is no longer cutting the mustard. Instead of trying to secure all things all the time, Security is taking a more holistic look at environments. Defense in depth is still a working adage in the security environment, but it can no longer mean full defensive capabilities at every junction, but needs to be modified to include automated responses to noted anomalies. Defense in depth has led to another member of the spaghetti problem, myriad protection, and monitoring points all with different interfaces and formats depending upon when they were introduced.
Think of it as moving from a position of medieval castles based protections to a satellite-based threat detection and response profile. As IT moves into its industrialized age from its period of artisan masters. Increases in production and scale are managed by automating simple tasks and moving that automation up the food chain.
As with any automated task, its output is known and expected. The output does not drift, as opposed to artisanal work which can vary depending on who did the work or even when the artisan master did the work. This makes monitoring from a security perspective simpler, any output that does not mark the normal expected output is an anomaly and as such is marked for investigation. This is the basis of SIEM; SIEM is Security Information and Event Management. What SIEM brought to the party was automated monitoring which “when” an anomaly was identified marked and sent an automated message to the relevant responsible human to deal with it. Although SIEM was a welcome advance in threat protection, it was not really an industrial age solution as it still required artisanal input for the response, and again we are in the realms of human error or bias.
Enter SOAR
Apart from having an awesome sounding acronym sounding like something from a Thunderbirds™ episode what exactly is SOAR?
The acronym stands for Security Orchestration, Automation and Response.
As a concept it allows businesses to collect and analyze data from multiple sources to identify security incidents within your IT systems and infrastructure. SOAR helps in the automation of threat management through a single, integrated interface instead of a separate tool in the toolchain for remediation, as is often the case with SIEM-tooling.
By default a SOAR product should contain three main components
- Security Orchestration: This refers to the integration and management of every security tool and resources at an organization’s disposal. Security orchestration helps teams to leverage all of their tools from a central location. “One Ring to Rule Them”
- Security Automation: This means using software tools to perform tasks that would otherwise need to be executed by human security personnel. Although not every type of security task can be fully automated, many can be, from cumbersome duties like updating firewall rules and auditing policy configurations to more advanced functions like threat triage, investigation and response can be automated. “One Ring To Guide Them”
- Incident Response: The act of reacting to and remediating security issues is called incident response. Response involves first interpreting alerting and monitoring data to determine the root cause of a security incident, then taking steps to contain and remediate the issue and ensure that the threat does not happen again. “One Ring To Bind Them”
SOAR and DevSecOps
While SOAR (Wikipedia) is a powerful set of products and a key enabler of DevSecOps; introducing a SOAR is not a simple task, as there is a steep learning curve. Like all technology implementations, you start small and pick the low hanging fruit. Define your current pain points and toil (what are you spending the most of your time on?). What can you move from manual to automated incident response?
Two good examples of a quick win for a security time is in the automation of the response to a Malware attack or to start the process of orchestrating your threat and vulnerability hunting across disparate systems in a holistic manner.
Herein is the problem of SIEM and SOAR based products, to be able to gain the most benefit of them, you need to fully understand the landscape, threats, what is normal and how to identify anomalies. This needs a skilled team both in terms of your chosen SOAR provider who is aiding implementation and also in terms of your company who will need to provide valid input as to normal working state and provide advice in regards to current working practices.
At a high-level implementing protection from a potential malware attack could follow the following set of actions.
Identify malicious activity: When dealing with any malware, it’s important to understand the signs that identify a potential attack, like an email from an unidentified address with an attachment, or an unexpected email from a known source with an attachment.
It is also important to understand how to stop malware in a timely manner to reduce the spread of infection. For instance, capture and verify the attachment, and deny the ability to run at-risk files.
The aim is to Automate processes to identify early indicators like misspelled process names or abnormal log activity.
Investigate the threat: When malware is detected, leverage your current workflows to analyze the errant application with your current toolset and use the relevant plugins to add the output in into your SOAR platform. Utilize your current sandbox tools to investigate the errant file. Use the plugins for the common sandbox tools to insert them into your SOAR.
Once integrated you can investigate any malicious files in a safe space, before they get into your network to cause real damage.
Containment and removal: All malware will require some type of containment/removal action. With your new rules in-place you can leverage automation to identify the affected users and assets, leaving decision points for security practitioners to remove the necessary user accounts, isolate the malware, or disconnect machines from the network or even automate your threat response.
OK, so it’s all about process again?
Yes, it is mainly about understanding process, but also a lot about knowledge. Outlined above is the three-phase approach to introducing a SOAR platform into an environment to improve a DevSecOps operational threat response. To repeat that and coalesce it down to a tight little ditty.
- Identify
- Investigate
- Contain and remove.
Identification is about knowledge and once that knowledge has been captured and turned into rules it can be easily automated, Identification is considered a low handing fruit, but it is a fruit that is long to mature, if you do not have the identification processes already documented and understood.
Integrating Investigation of anomalies into your process is a workflow mechanism. “if A is identified then do B” this is most likely a manual process, SOAR will use the identification of an anomaly as in input to the investigation stage, this requires automating your current process by using the relevant tool plugin to insert the file into your investigation arena. There the file can have things like is SHA1 and MD5 algorithms verified against your acceptable versions.
This section will bizarrely result in quicker acceptance withing your security team than the initial identification stage, as it is more technology-driven and uses known and accepted tests.
Finally, we move to Contain and Remove this is the final arrow in the quiver of the SOAR product set. and the simplest to bring to fruition.
Summary
The biggest issue about implementing Automation products is the inertia regarding the early stages, the work needed to start an automation project is hard. Enterprises and SME to an even greater percentage, have very poor documentation and understanding of the processes and procedures that go into day to day easily automated work. There is also political inertia; the concept of automation worries people regarding their positions.
Security is a very artisanal master-led profession. But information technology security just like its physical sibling and IT, in general, is rapidly approaching its industrialization stage, and SOAR based technology is one of the major enablers in that process.
Security automation is coming and not just because it will increase productivity and protect assets, but because it just makes sense humans are amazing at sifting out anomalies but they are slow, rule-based algorithms that have been trained to detect none standard responses are just quicker at identifying them, and they get better when trained; Security professionals currently spend their time monitoring and reviewing logs from across the enterprise. This time would be better spent training their solutions to spot and deal with threats, allowing those professionals to investigate the next new threat vectors and also give them time to actually investigate new technology at the same speed as their colleagues in other IT Departments. That is why DevSecOps and tools like SOAR will become a massive part of the security team’s armory in the near future.
