Because a security decision without friction is just resilience without reality.
Since I’ve been more involved in blue team operations and the corresponding decision making processes, it has been similar to the experience of waking up, going into the shower, turning on the hot water and being shocked into reality with an avalanche of ice cubes.
That feeling of reality being the opposite of your expectation, reminded me of when I stood on the side lines as an advisor or when I performed offensive operations and had to agree on rules of engagement, scope and if we would attack production or not. There are many opinions on if you should target production or not, my personal opinion is that performing attacks on production are the the only way to have the most assurance that all measures and processes are working as intended. With this, I don’t exclude performing certain tests on test or acceptance environments first due to many reasons we are all well aware of.
Now, the above paragraph is an example of the reluctance of touching production. This reluctance and paradox on improvement versus impact, exists as well and even more on the defense side as we will see later on in this blog post.
This fear is usually exhibited, with the following question:
…but what if you bring the system down or disrupt our business process?
Which on itself is a very valid question to ask. However, what usually followed, in the same breath, always seemed a bit off for me. Because in a lot of situations it ended with:
We cannot permit the slightest down-time or business impact due to security testing.
Which, again, on itself is a valid concern or statement. However, if we add the context of: are you then prepared to quickly recover if it goes down due to an actual attacker? It changes what a valid answer could be.
For me back then that answer provided an unexpected insight. We feel more comfortable prioritizing a stable environment based on assumptions, than a resilient environment based on reality.
What I was and still am really missing is the replacement of fear with the realisation that it is an opportunity to improve the resilience of those systems and processes. You have the best ingredients to achieve this, since you know and work with the attackers.
If something goes down you CAN actually perform root cause analysis with the ‘attackers’ being part of that process. Yes, you will still incur business loss or said in business terms ‘paying your resilience premium’. However, if properly executed and used as an opportunity to improve you will have less losses during a real attack.
The usual way forward is of course to build in a myriad of cautious technical & process steps to minimize the chances of the security test bringing down the system in scope and/or impact the business process. Which basically leaves the brittleness in the same state as before the test.
There is no friction for the decision maker, the entirety of the risk can in the offensive example be offloaded to the testers or the systems can be taken out of scope, that’s it, problem solved.
If we now switch back to the blue team side, I see that same frictionless decision making playing out. A different example, but the same thought process, is the classical:
* Allow response on all employees
* Exclude certain employees due to business impact
The second decision is frictionless you don’t have to take any further action or think about it. You’ll just deal with it, if it ever happens. The first decision creates friction since it forces you to think about:
* What parts of the work flow of that employee are the really important aspects of their workflow and how can you facilitate that workflow while at the same time responding to an incident on their workstation or account?
For example, what if the critical process of their workflow is email. And we would be able to understand that 30m of email downtime is acceptable? This would give the blue team 30m to isolate and if not resolved at least allow the email connection to carry-on, accepting the risk of that being part of the attacker communication flow, but preventing all other communication.
The answer is a lot of time “business impact” without really fully defining it, since after all, it is easier to choose the option with the least amount of friction.
We must start to define 'business impact' together; the business and the security teams. Otherwise we will forever be stuck in a frictionless decision process.
As long as we don’t change this mindset on the blue team side, no amount of tools will truly help us. AI as well as many other forms of automation have the capability to change the game at scale for defense, but they won’t achieve their full potential if we don’t change our decision making processes.
Makes you ponder if the following could be true, since instinctively it contradicts the mantra of making security frictionless to achieve greater outcome. My personal opinion is that to get to invisible & effective security you need to put in the effort (friction) to truly understand the problem space.
The Law of Frictionless Security: If a security decision requires no change to a business process, it likely provides no change to your actual resilience.
DiabloHorn 