SOC Capability Area #16) Security Orchestration

Before considering Orchestration capabilities that support automating response actions, it is important to identify exactly who (e.g., Security Operations, Network Operations, the affected system owner, etc.) will actually take these actions. It should not be assumed that Security Operations will always take the action.

Regardless of who responds, the simplest of capabilities in this area include remote access tools (such as SSH, RDP, psexec, VNC, etc.) that support direct manual intervention. Network Operations will likely also have a range of commercial systems and network management capabilities (e.g., IPMI compliant tools such as Dell's iDRAC, HP's iLO, Oracle’s ILOM, etc.) to support direct manual action. But manual responses can quickly overload Analysts and Operators, so automation capabilities should be considered.

The “Security Automation and Orchestration” (SAO) marketplace of solutions has grown out of the need to automate vetted, pre-approved incident responses to familiar, recognizable attacks and compromises. However, there is considerable ambiguity and inflated expectations today regarding the practicality and effectiveness of such solutions. Automating security actions has been the core theme behind several earlier generations of security technologies; including vulnerability auditing and automated patching (which has evolved into DevSecOps today), signature-based anti-virus and anti-malware, intrusion detection/prevention systems (IDS/IPS), and most recently endpoint detection and response (EDR) solutions.

The need is obvious – take the human “out of the loop” to both accelerate the response (reducing Mean-Time-To-Respond or MTTR), and address significantly more issues and/or incidents per hour. However, such orchestration (automation) capabilities are inherently based on a set of unspoken assumptions that do not always hold true:

• First, that these are familiar, “commodity” situations, automatically recognizable by the deployed sensors and detection capabilities (either signature or anomaly based).
• Second, that the circumstances are well-understood in advance and false positives can be easily avoided or at least minimized.
• Third, that an appropriate response can be identified in advance and pre-programmed into automation rules.
• Fourth, that applying an automated response in real time is not going to result in further, more significant impact to the organization’s business and users.
• And lastly, that Security Operations has the actual authority to decide on and apply a response.

Security Orchestration (automated response) capabilities are very useful, but are not a panacea, need regular maintenance, and are most useful for “commodity” incidents. When dealing with situations that are less familiar, involving more “novel” adversary techniques and tactics, pre-orchestrated response becomes a great deal more challenging.  For years now, Artificial Intelligence (machine learning) has promised to remove the need to pre-program this orchestration.  However, the learning (supervised or unsupervised) required to train such models has proven ineffective for anything more than commodity types of attacks. 

It should not be surprising that threat actors are aggressive early adopters of such automation capabilities, specifically to test their own malware and to practice their tactics against them. Some have become very effective at using both evasion and deliberate distraction techniques to subvert such automated controls to their own benefit. The “novelty” situations that such advanced attackers create often demand experienced human intervention and intuition to better comprehend what is happening and what the appropriate set of response actions should be.