Just this week, I was reviewing several interviews I conducted with cybersecurity professionals on their organizations’ processes and tools for incident response (IR) automation and orchestration. Here are a few things that jumped out at me:
1. IR is still often anchored by basic tools, manual processes, and key personnel.
While trouble ticketing and ITSM tools are pervasive and fairly mature, too many enterprise organizations still “ham and egg” it through incident response. In other words, they rely on paper forms, spreadsheets, email handoffs, and some socially-challenged security analyst who’s really good a finding compromised systems and malicious network traffic.
2. Organizations try and use commercial tools.
Many try to kludge their way through this with Remedy or ServiceNow ITSM but these tools were designed for IT operations and help desks, not incident responders. Typically, the SOC team wants to track incidents throughout their lifecycle but can’t do so effectively with IT operations tools.
3. There’s a lot of homegrown software out there.
Many firms that try to move beyond informal manual processes often cobble together scripts, applications, and databases for IR purposes. Sometimes, they use open source tools like FIDO from Netflix or RTIR. While these efforts are certainly well intended, they seem to fail when they lack functionality, scale, and ease-of-integration. Furthermore, most security organizations don’t want to be in the business of developing and maintaining software.
4. IR is moving from reactive to proactive.
In the past, the discovery of a severe incident led to actions like capturing network packets (PCAP) and deploying endpoint forensic tools to look for suspicious artifacts, files, and in-memory processes. Many organizations have moved or are moving to continuous monitoring of networks using tools from Arbor Networks, Cisco (i.e. Lancope), ExtraHop, RSA, or Symantec for network security analytics and Carbon Black, Countertack, Cybereason, Endgame, or Guidance Software on endpoints.
5. Initial objectives tend to be around orchestration first…
Security professionals realize that some type of IR process like gathering and enriching security data, investigating phishing emails, or looking for IoC activities on hosts and networks require a multitude of manual steps that take hours or days to complete. I’ve found that many organizations start their IR automation and orchestration projects by mapping out one of these multi-stepped processes, and then using orchestration tools to let technology alleviate a lot of the heavy lifting. Once one process is orchestrated, organizations tend to build upon what they learned by orchestrating other tedious tasks. This makes sense as almost every organization has a cybersecurity skills shortage and wants to make the existing staff more productive.
6. …But automation soon follows.
Again, organizations tend to start with the basics – terminating a network connection, quarantining a system, blocking connections to an IP address, etc. This is especially true as organizations mature and operationalize their threat intelligence programs.
IR automation and orchestration is also evolving into a key piece of functionality for an evolving security operations and analytics platform architecture (SOAPA). Here’s ablog I wrote about SOAPA recently.
When I started covering this space a few years ago, enterprise organizations either rolled their own IR automation and orchestration solutions or simply remained buried by security alerts and manual IR processes. Fast forward to 2017 and IR automation and orchestration projects seem to be well under way or on every CISOs short list.
Given this flurry of activity and interest, it’s likely that IR automation and orchestration as well as vendors like CyberSponse, FireEye (Invotas), Hexadite, IBM (Resilient), Phantom Cyber, ServiceNow, Siemplify, and Swimlane, will get ample attention at the RSA Security Conference next month.
Join the Network World communities on Facebook
to comment on topics that are top of mind.