Welcome back to my blogging adventure. If you’ve been reading along, you’re aware of the lightbulb moments from my article, “echo: hello world”, that allowed me to discover the benefits of an analytic approach to cybersecurity. Next I gave a little slice in the life of our intrepid SOC analyst in, “Cybersecurity: the end of rules are nigh”, where I gave a little detail behind my belief that we need to move away from a rules detection approach to cybersecurity monitoring. Today, we will spend some more time with our SOC analyst living the life of event triage. My hope is we come away with a greater understanding of why context matters as I show a high level process for efficient incident response triage.
To understand why context is so critically important we need to forget about technology for a moment and focus on people and process. A hard lesson I’ve learned in my career is that when we focus on the technology we end up creating solutions that make the person work for the machine instead of the machine enabling the person. So let’s take a moment and get in the shoes of our intrepid SOC folks and walk through a day in their lives.
The short term goal of any analyst is to get away from the triage cycle and move up to the role of the security engineer. Typically, the security engineer’s primary responsibility is the care and feeding of one or more point security solutions. They do capacity planning, system maintenance and upgrades, and be available to assist if their technology is part of an incident response escalation. The promise is a standard work day with the occasional off hours call if incident response is required. The reality is change management requires all maintenance be done outside of business hours and incident response means helping the triage specialists at all hours several days every week. Since the point security solution is probably a rules or signature engine, the security engineer spends many hours dialing down the rules generating most of the false positives.
Hopefully, everyone got through that heavy dose of sarcasm and realize that not once did I point the finger at technology products and say our solution’s better. If you think I was being hard on the people involved, ask your people and see if they didn’t feel or think that way at least once in their careers. They may laugh, or they may cry, but we’ve all been there in the trenches trying to understand what’s going on when we know minutes matter.
Yes, we have a real problem with incident response and new technology will be required to help solve the problem; however, the fundamental problems are in the people and process interacting with complex non-integrated technologies where the people and process is made to work around the technology. Until we as a security community fix that, any new technology such as security analytics are just going to create more alerts that are going to fall on the floor without review.
So, how do we make the technology work for us – to enable us to do our jobs efficiently and effectively? Let’s spend a minute talking about the high level goals and objectives this ideal business process solution should solve.
The investigators spend weeks rebuilding a chain of custody as they determine the root cause. Wouldn’t it be great if they didn’t have to? This is weeks of effort spent on highly skilled individuals or third party consultants charging hundreds an hour that could be saved. This needs to be inexpensive enough to hold all the data for several years.
I gave a hint above that this data has value beyond security. IT and business process could be made more efficient if the full context was made available to everybody. This is core customer facing experience improvement driving impact to the bottom line. This requires a highly scalable data repository that enables open integration with every vendor technology – this means open standards without proprietary extensions.
No, I’m not talking a SIEM. I’m talking about a user interface that allows you to automate your response workflow and visualization needs. Why should you bend your process and people around someone else’s dashboard solution? I’m talking about an open and extensible user interface that acts as the single console for the SOC triage analyst.
As I keep saying, the value isn’t in the pretty dashboards; it’s in enabling timely action. Open integration with technology products to trigger automated response. Why wait days to pull a forensic image of the machine after it’s been trampled by layers of IT folks when leveraging network forensic tools can collect the image minutes after the malicious activity occurs. Why wait to have the SOC triage analyst click the big red button to respond when you can automate network and system blocking or even DevOps container reloads from known good builds. Yes, it is a hard political battle to get automated response approved, but with an analytic platform you can simulate the response of the last three years of data and show it wouldn’t have caused an outage.
In my next article, we will start to move away from why we should build an analytic first cybersecurity solution and the value it can provide, towards actually describing what the solution should look like and how Hortonworks can be part of the solution. In a future article, I plan on spending a day in the life of the CISO as they struggle developing their security strategy and justifying their budget. Who knows, maybe analytics can help.