[BreachExchange] Getting security ‘right’

[Audrey McNeil]

https://www.csoonline.com/article/3278057/data-protection/getting-security-
right.html

There always seems to be plenty of security news to talk about. Someone is
making some sort of mistake pretty much all the time. Everything from
vulnerabilities in software to organizations getting hacked. We hear about
horrible data leaks, bad passwords, configuration problems, credentials
checked into github, cross site scripting, the list is nearly endless.

This is quite convenient when one is trying to write a security blog,
there’s never a shortage of topics. It really is a problem though, it’s
pretty clear it’s really hard to get security correct. It’s a pretty safe
statement to claim nobody will never get security right all of the time.
The bar is pretty low today.

Almost every time we hear about some sort of security problem, there is
inevitably someone will talk about “doing it right”. When they put together
their compliance program, they’re going to do it right! When they build out
their security policy it won’t be all fluff, it’ll be done right! Secure
development? Again, we’re going to do it right, not like all those other
chumps we keep reading about in the news! They’re going to build the
perfect infrastructure that won’t have any the problems we keep reading
about.

It sounds like a great idea, why would we do something only half way when
we can do it all the way and make sure we do it in a way that will solve
all of our problems? There is a problem with this plan.

There is no such thing as doing it right

In the comic Calvin & Hobbes there is a game called Calvinball. The game
has no set rules, the players make up the rules as they go. The only rule
is you can’t use the same rule twice. A huge game of Calvinball is how I
would describe IT today. What we call security is just another part of the
game. What we do today can be, and often is, completely changed tomorrow.
Sometimes things get changed by accident, sometimes it’s done on purpose,
but nobody is told about the changes. Sometimes the plan is basically to
have no plan. The world of IT today is nothing like anything we’ve ever
seen before. Things move really fast, faster than anyone can really
understand.

If everything around us is changing constantly and quickly how can we
possibly “do it right”? The short answer is we can’t possibly do anything
right if our definition of right is rigidly defined. The mental concept of
doing something the right way also depends on having a system that isn’t
constantly changing. Humans thrive on slowness and stability. We believe we
can do things properly and correctly because we see the system as it is
today. We don’t see the change that’s happening or the future that’s not
yet clear to us.

If you have even a moderately modern infrastructure in place everything is
changing very quickly. The days of setting up your network and servers and
only worrying about changing things once or twice a year is long gone. I
have a suspicion if you have the sort of infrastructure that never changes
you probably won’t be reading this blog. It’s probably safe to say if
you’re reading this, you have infrastructure that’s changing on a pretty
regular basis.

I’m not trying to claim there is anything wrong with change. I think having
the ability to move very quickly is a huge competitive advantage today. You
don’t hear stories about successful businesses who are moving slowly and
keeping their infrastructure the same. We read about companies that are
throwing out all the old rule books. They’re moving faster than everyone
else, the speed is one of their biggest competitive advantages! Most of the
companies known for moving slowly we read about in case studies about
failure. Slow and steady doesn’t win the race anymore. Maybe it never did,
fairy tales can be funny like that sometimes. How many of these stories
focus on “doing it right”?

If you’re familiar with DevOps you’ve probably heard the term Minimum
Viable Product at some point. This is something DevOps does that we could
all stand to learn a lesson or two from. The idea is basically instead of
building something that’s perfect and correct (and slow), just build
something that works and ticks the box. This should probably sound familiar
right about now. If you try to build the perfect solution you will end up
moving very slowly and, in most instances, you never actually finish
anything because you’re too focused on a mythical finish line instead of
actually solving problems.

This is what I mean when I say there’s no such thing as doing it right. You
can solve a problem, or you can work on something long enough the end
result won’t matter by the time you’re done. When you move too slowly
everyone else will find ways to go around you. Shadow IT became a thing
because some groups found it easier to do their own IT than to work with
the existing IT groups. This is one of those instances where you shouldn’t
be blaming the users, you should be blaming yourself.

The job of infrastructure isn’t to build infrastructure, the job is to
solve problems to help the rest of the business succeed. Sometimes we lose
sight of this goal when we obsess with ideas like doing things right and
building the perfect solution. If your business isn’t moving fast today one
of your competitors will which won’t have a happy ending. If your
infrastructure can’t move faster than your business, you have a problem.
Perfect or right are both concepts that hold back proper innovation. It
seems counterintuitive that trying to do something right is the wrong
answer, but it’s not about doing things right as much as enabling everyone
else to do the things they need to do. It’s a lot like all those stories
where the hero gets what they need, not what they want. We want to do
things right. Doing things right is what we want, not what we need.

Do what needs to be done. There’s no such thing as doing it right. There
never was, there never will be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180605/9bbfc74f/attachment.html>