In the wake of recent data breaches, a story bubbles up with an ex-employee citing knowledge of the dire security conditions. Usually it includes an unsubstantiated comment that the executives were given warning of the problem.
The conclusion is often along the lines of “when will executives wake up and do something?”
Executives are concerned. They are acting. And in the process, they’re trying to follow our guidance. All of it. In fact, we’re offering too much guidance.
That’s where we need to get better.
Perhaps you’ve uttered or heard the phrase that ‘attackers only have to be lucky once, but we have to be right all the time.” To be fair, I’m confident I shared that little nugget at various points over the last two decades. In the process, that becomes a justification for tireless efforts, sleepless nights, and a never-ending list of things that needed to get done… yesterday.
Doesn’t make it right.
It’s counterproductive to point fingers in the wake of a breach with claims of “told them so.” After the breach, what should have been done is painfully clear.
Did we really tell them - before the breach?
If the solution to be prepared against a never-ending onslaught is a seemingly endless list of things that need to be funded, it often creates more confusion than solution. If “telling someone” involves a lengthy list, of which they can afford 3, did the advice help?
Not likely.
What the business needs
Most organizations - including non-profit - provide value in a way that creates revenue. That means security professionals need to understand, clearly, the essential elements and functions involved in capturing that revenue.
Our colleagues in the business have their own concerns (rightly so). They aren’t necessarily spending a lot of time understanding emerging threats. They have an expectation that the security team will prevent a breach. That, in part, is driven by our bias for breach prevention.
What the business needs is an understanding that breaches are inevitable. And that’s okay. Consider it the opening of an important and ongoing dialogue. It guides a shift to align our actions and efforts across prevention, detection, and response with what is most important to the business.
The business needs to reasonably expect that we’re protecting what matters most. In the cases when an attacker bypasses prevention, our role is to quickly and accurately detect so we can appropriately respond.
What it means for us
Aside from the obvious need to gain a better understanding of the business, we need to get better at prioritizing. It’s a combination of connecting our actions to expected outcomes, measuring what matters, and using available intelligence to prioritize. It breaks into three broad goals:
-
Focus on understanding the business (perhaps better than the business does)
-
Measure our tools, processes and solutions; we need to know which solutions deliver the best returns, which we need to shift, and those that are due to be retired
-
Prioritize based on value and returns
If we expect the business to define the top 3-5 initiatives (and we certainly do), then it’s only reasonable that we do the same. More, our top initiatives need to clearly demonstrate their value to the business. We must explain how our efforts benefit the top initiatives and beyond.
For some this is a subtle shift. Some teams might experience this as a sea of change from the way things operate. The more evidence we gather -- and share -- the more successful we’ll be individually and collectively.
This is a call to action
Learning of a breach in the paper is a bad way to start a day. When it happens -- and it’ll keep happening - we need to stop with the snark. No more “told you so.”
It also means we need to stop with the ‘kitchen sink’ approaches because ‘attackers only need to get lucky one time.’ Instead, we need to prioritize efforts in a way that works for our business. Make the choices clear and actionable.
Help build the future: what skills, tools, and other changes do we need? Share your thoughts in the comments (I read them all), engage with me on Twitter (@catalyst), or drop me an email.