I'm busy working on my blog posts. Watch this space!
On Risk Assessments
March 7, 2018
At EAmmune, we do risk assessments very differently.
That statement could easily be one of our taglines. In all honesty, it's a direct result of my own rather passionate view that the way RAs are generally done is... well... stupid. I don't care what framework you're using, what standard you follow, and how much lip service you pay to risk management, I am willing to lay odds that your RAs never make it anywhere outside of technical teams (except the mandatory management meeting where everyone pretends to care).
It's practially in the nature of how they are done.
Take a look at ISO27005, a supposedly gold standard for these: the entire way they frame it pretty much anticipates - demands - that your risk assessment results will have things like rankings and scorings and "treatment plans", and when you read closely, you will see that those assumptions kinda mirror the expectation that your "risks" are - for all intents and purposes - technical faults. It may be dressed in fancy language and overly formal definitions (count on ISO to always be overly formal), but that's all there is to it.
Pretty much every other RA standard out there does this.
Why? what's the purpose? why on earth would I want to create yet another burdensome process to let everyone know what my vulnerability scanners and pentests and other technical assessment tools already show on a regular basis? what am I adding to my risk management program by relisting these kinds of findings in yet another way?
So we don't do that. I refuse to do it this way.
Here is what we do instead. Let me shock you.
Our RAs are interviews only. Open-ended ones (first question is always: "what keeps you up at night?"). Yes, you heard me right. We do not inspect any system, examine any data repository or vulnerability report, or check in with any non carbon based lifeform. We explicitly ignore this stuff entirely, by design. The approach is literally writtren right into our ISMS governing document.
Because in our view, the RA should attempt to nail down at all the things that the people - not the machines - in the organization know, suspect, expect, despise, ignore and abuse. We want the dirt, the rumors, the politics and frictions and infightings.
Why? because security is a people discipline, that's why. Read my book for more on that.
But also because the technically oriented assessments are done routinely anyway (through all the various means one performs this). People assessments are never done at all - and no, performance reviews and background checks every 2 years do not qualify, although it's a great control. When I say people assessments, I mean the hard work of understanding where their mind is with respect to the company.
And that is because if you ask enough people, with a good representative cross-section of the company, and utilzing your people skills, knowledge of psychology, business understanding, and outright snifferty (yes, I just made that up because I'm too lazy to find the proper dictionary word), you will always find everything that's really dangerous in any organization - without ever touching a single damn system.
In fact - and here is one of our little secrets - one of the ways in which we internally determine how real a particular risk might be is simply if it gets mentioned by more than one person. The more people bring up the same thing (and it's up to us to understand the internal correlation between disciplines), the more weight we give to that correlated finding.
Put another way, people know where bodies are buried, because they are ones who dug the graves. Doing the RA the way y'all do them is like examining the shovels. Interesting nick patterns, and you may even figure out a hole or two in the ground based on the dust grains, but the cemetaries? you'll never know. Those shovels were buried alongside the bodies.
I can say a lot more about this - the EDPACS article I wrote last year touches on this as well - but the reason I was reminded of it today was that I just finished writing the narrative for one.
Which brings me to the other big difference in how we do these.
Our interviews, by design, lead to a narrative. A story, if you will. An actual, honest to goodness, 10-page or so customized booklet written from scratch, with 90% fresh content, for each and every customer. It's an easy read. It has, at most, a tiny amount of technical reference, like an acronym or two (usually uninentionally). It frames the assessment, and gives you an idea of what is really dangerous to the business, in terms of practices, expectations, direction, strategy, and so on. It is always grounded in where the business is trying to go - not just any business, but explicitly that business, at the time we perform it. It's a highly accessible document, intended to be understood by any laymen. It doesn't tell you which "weakness" you can "remediate" in X weeks, but rather, what are the real, structural issues that may threaten your existence, based on the current strategy and future plans, and tries to highlight the kinds of problems that fester and rot inside organizations.
But it's also, to be frank, a bitch to write. It's like a mini-novella. There is very little repetition between companies, because each has a different business context, cycle, and challenges, even if they are competitors. It requires creativity, and does not rely on copypasting or filling in the blanks. There is no form template to use, a set of pre-written answers in pulldown menus that you can pick from.
That makes it a lot harder than just following the instructions and filling in a matrix.
But I swear this stuff really works. These RAs are not always even shared with technical teams, let alone used to set down any direction for them, except in a strategic sense. Our RAs are, usually, the domain of the senior leadership team, often solely the senior leadership team. It's not even a matter of being heard, because it never isn't (don't you love double negatives?). Our challenge is usually in calibrating the response.
You know. Like what all those frameworks claim you should be doing, except they rarely if ever actually succeed in getting there.
Where I get particularly irritated is when I deal with auditors who have been trained on the "one and only way" to RA... and don't even have the desire, let alone enough of a business background to understand anything else.
Anyway... long way of saying, one more done, I swear, these take a lot out of me.