This is the second post in the Automating Cyber security series – the first being back in October (I really need to speed this up!). In this post, I would like to simply share a train of thought with you which will lead, I hope, to a rough scope of the problems we face when considering automation of cybersecurity process.
What do I think about when considering automation of cybersecurity?
- Automating the mundane. If you are responsible for implementing policy – turning that insomnia-curing document into something actionable for your enterprise, then you know what I mean. The mundane aspects of what we do seek to automate the process points that keep humans in the loop. Given the shortage of qualified security personnel, automation is pretty much viewed as a requisite through this lens. The more we can increase the effectiveness of one human security resource, the better off we are overall. Of course, automation presents its own challenges as well, as we will see further on in this series. At Tripwire we have recognized that we are embedding security into IT process and that automation is a good thing, but why? The primary driver today is for the sake of compliance, which presumably is done for the sake of security. Further, you can’t really talk about compliance without talking about reporting. After all, how do you prove that you’re compliant to a given authority without relying on and/or generating some type of report?
- Analysis is also critical from the security perspective and from the automation perspective, as will become clear as this topic is further explored. The real problem is that we’ve got the same analysis being performed with the same, or at least very similar conclusions being reached by a multitude of security practitioners. It seems reasonable that automating this common analysis to the maximum extent would be desirable.
- Adapting. It’s a simple word. It complicates things significantly. The question is not whether we can adapt – we do this all the time. Instead, the question is how long does it take us to adapt? I assert that adaptation is the critical question moving forward in this industry. If we can’t get to the point where we are adapting as fast, if not faster (i.e. anticipating), than the bad guys, we’re eventually done for. I’m not sure we can do this, but it would be pretty interesting to conceive of a mathematical proof (by induction, maybe?) to prove what seems obviously true – if we don’t adapt as fast as the bad guys, we’re always reacting, always behind, always losing on some front. For automation to adapt – and this is an important implication – we must create some foundational models which enable our adaptation (i.e. they do not hinder us) and other models that can adapt themselves.
Many of these ideas are little more than jotting thoughts down. The theme to extract from this train of thought is that IT security processes are a subset of IT processes, which are a subset of business process, and these processes interact at various points with humans – this is where automation of cybersecurity will play a key role in the future.
In that light, what humans are involved in the business processes affected by cybersecurity? It turns out that there are many, a fact to which our UX team would attest. Consider the following concerns, which is by no means a complete list:
- Security Operations
- IT Operations
- Policy Definers (internal and external)
- Policy Implementors (translating policy into action)
- Auditors (internal and external)
- Asset Owners
- Information Owners (as a subset of Asset Owners)
- Law enforcement
There are a lot of opportunities here for processes to require a human’s touch, and our goal is to identify the set of touch points that do not necessarily require a human’s touch. This is quite a challenge, and really brings the scope of the problem into focus.
The next question to answer is: Where do we start?