I’ve been a little absent from this blog for a while, mostly because I’ve been settling in to a new job where I’ve briefly changed my focus almost completely from application security to being a software developer.
The blog absence is going to change now, and I’d like to start that with a renewed effort to write something every week. In addition to whatever grabs my attention from the security news feeds I still suck up, I want to get across some of knowledge and approaches I’ve used while working as an application security guy. I’ll likely be an application security guy in my next job, whenever that is, so it’ll stand me in good stead to write what I think.
“One Simple Thing”
The phrase “One Simple Thing” underscores what I try to return to repeatedly in my work – that if you can get to the heart of what you’re working on, everything else flows easily and smoothly.
This does not mean that there’s only one thing to think about with regards to security, but that when you start asking clarifying questions about the “one simple thing” that drives – or stops – a project in the moment, it’s a great way to make tremendous progress.
The Simplest Security Thing
I’ll start by discussing the One Simple Thing I pick up by default whenever I’m given a security challenge.
What are we protecting?
This is the first question I ask on joining a new security team – often as early as the first interviews. Everyone has a different answer, and it’s a great way to find out what approaches you’re likely to encounter. The question also has several cling-on questions that it demands be asked and answered at the same time:
Why are we protecting it?
Who are we protecting it from?
Why do they want it?
Why shouldn’t they get it?
What are our resources?
These come very quickly out of the One Simple Thing of “what are we protecting?”.
Here’s some typical answers:
- Our systems need to continue running and be accessible at all times
- We need to keep making money
- We need to stop [the risk of] losing money
- Our customers trust us, and we need that to continue
- We operate in a regulatory compliance climate, and need to keep our lawsuits down to close to zero
- We don’t even have a product yet, and haven’t a clue what we need to secure
- We don’t want a repeat of last week’s / month’s / year’s very public security / privacy debacle
- We want to balance the amount we spend on security staff against the benefit it has to our bottom line – and demonstrate results
You can see from the selection of answers that not everyone has anything like the same approach, and that they don’t all line up exactly under the typical buckets of Confidentiality, Integrity and Availability.
Do you think someone can solve your security issues or set up a security team without first finding out what it is you’re protecting?
Do you think you can engage with a team on security issues without understanding what they think they’re supposed to be protecting?
You’ve seen from my [short] list above that there are many answers to be had between different organisations and companies.
I’d expect there to be different answers within an organisation, within a team, within a meeting room, and even depending on the time I ask the question.
“What are we protecting” on the day of the Equifax leak quickly becomes a conversation on personal data, and the damaging effect of a leak to “customers”. [I prefer to call them “data subjects”, because they aren’t always your customers.]
On the day that Yahoo gets bought by Verizon for substantially less than initially offered, the answer becomes more about company value, and even perhaps executive stability.
Next time you’re confused by a security problem, step back and ask yourself – and others – “What are we protecting?” and see how much it clarifies your understanding.