Limitations

It's great to be confident. But, to quote Dirty Harry in Magnum Force, a man's got to know his limitations.

I'm not going to go into the Capability Maturity Model in this post - you can look it up yourself.  I don't really like the idea of giving an organization a single score on their capabilities, because I think most organizations are great at some things and pretty terrible at others, and you lose a lot of resolution if you try to pack all of that into one step.

I do think that a lot of organizations are delusional about their capabilities.  I recently read a Computer Weekly article by Warwick Ashford saying that 60% of the organizations they surveyed had had an outage due to digital certificates in the past year.  Sixty percent of organizations are having trouble managing their certificates.

In case you hadn't heard, certificates are the foundation of the Secure Web.  Browsers are starting to break sessions if the certs aren't good.  In words of two syllables or less: If you can't do certs, you will fail at the sexy stuff,  Stuff like automation, single-sign on, big data, AI, and all the other cutting-edge things your boss wants you to do this year. 

Almost any next-gen technology you build is going to rely on your infrastructure, and if  you're having trouble with foundational capabilities like certificate management, or DNS, or routing, you may want to seriously rethink your roadmap.  Maybe it's time to stop fishing and cut bait for a while.

After all, a man's got to know his limitations.

Positions and Interests

Cybersecurity can be a pretty charged subject.  We argue that a finding presents a serious risk, while the system owner and O&M team insist it's a false positive, or it's not a risk, or that it's too hard to fix.  We go around and around, and both sides become more and more convinced of thier rightness and dig their heels in deeper and deeper.  Pretty soon, we have to call management in to mediate and, as often as not, things don't go our way.

In their classic book about negotiation, Getting to Yes, Roger Fisher and William Ury underscore the difference between a position and an interest.  Our position is what we're asking for. Our interest is why we are asking for it.

In the case of our finding, our position is that the finding puts the organization at risk, while the system team argues that it doesn't. Our interest is to make the organization more secure, or to resolve an audit finding, or simply to check a box.  The system team wants to focus on functional requirements, not technical debt.  Their feelings may also be hurt because you are implying that they didn't do good work. 

When both sides take entrenched positions, someone usually has to lose in order to make any progress. This leads to bruised egos and even tougher positions next time.

It always pays to step back for a moment and ask yourself why you are taking the position you are taking.  What do you really want out of this engagement?  What does the other side want?  It's possible that your interests are aligned, or even overlap, in places.  If you can find those places, you may be able to reach a solution that meets both of your needs.  

In our example, we all want to have a secure, reliable system.  It might help to reframe the issue as a quality issue - it could cause the system to behave erratically, or it could cause an outage.  The team doesn't want extra work.  You don't want an audit finding. Is there a way we can mitigate the issue without the team having to do extra work, like putting it behind a proxy or a firewall?  By framing it as a potential quality issue, can we get the system team to do root cause analysis?  Maybe the problem is easier to fix than we thought.  

You have to get to a place where you can negotiate before you can get anything done.  This can happen a lot faster if you back away from your own position and focus on everyone's interests instead.

Responsiveness vs. reactivity.

What do you do when you encounter something new, something hard?  In our world, we are bound to run into things we don't know how to unpack or process or deal with.  None of our current tools seem to work.  The easiest thing to do is to react: get busy and attack the problem with tools and strategies that, although familiar, clearly aren't suited to solve the issue at hand.

Even though you know a fork isn't the right utensil for eating soup, rather than pause and search for a spoon, you try to compensate by working harder.  You scoop up tiny forkfuls of soup as fast as you can so everyone can see you're working as hard as you can to empty the bowl. 

But you aren't doing your best - you're just wasting a lot of time and energy in a very unproductive way.  

Stop.  Reflect on the situation for a moment.  Ask for help.  Ask for advice. Search the web for "best utensil to eat soup".  Take a few minutes and go find a spoon.  Buy one if you have to.

It takes discipline and confidence to stop reacting, to take a moment in order to determine the most effective way to respond to a pressing issue.  You need a good answer for the boss if she sees you sitting around thinking while that expensive soup is getting cold.  She needs to explain to her boss why nobody's doing anything about this problem.  Tell her the soup will get cold by the time you're done trying to eat it with a fork, anyway.  And if you don't take the time to get the spoon this time, then next time, you won't have the right utensil to do a better job emptying the soup bowl, either.  If you can convince the bows to let you invest the time into finding a better solution to the problem this time, you'll save everyone a ton of time, money, and frustration down the road. 

Respond, don't react.

"What does eating soup with a fork have to do with cybersecurity?", you ask.  Everything.  

Flywheels and Bullets

Why are high-performers so much better at executing?  They seem to be able to take on new work and initiatives almost effortlessly and even gain momentum in the process. How do they do it?

There is never a single decision or action that will propel you to excellence.  Success is incremental. Jim Collins, author of Good to Great, writes of what he calls the Flywheel Effect.  Rather than thinking of work as a series of steps, think of it as a well-placed nudge to a wheel that is already in motion.  If you exert the right degree of force at the right inflection point, you will increase the momentum.  It will feel inevitable: if you do A, you almost can't avoid doing B, and C just follows naturally, and so on.  This builds organic momentum.  

Now the problem is discovering what actions propel the flywheel.  Experiment.  Fail as much as you have to, but fail small.  Fail early.  Fail when it's cheap and easy to clean up any mess you make.  Most important, fail while you still have momentum so you can course correct and find the right way to build momentum.   The key is to fail until you find the sweet spot, the synergy. Then you stoke it patiently over a long period of time and you will see that your results begin to amplify.  You will also begin to discern an underlying logic that you can extrapolate into other categories of work. The flywheel principle explains why the Lean principle of failing fast is such a key element.

Another of Collins' dictums is to fire bullets first, then fire a single cannonball.  The idea here is that you can significantly reduce risk and maximize return by starting.  Fire as many bullets as you need to in order to get your range and windage.  Then when your target is within perfect range, and you are hitting bulls-eyes with the small bullets, bring out the big gun, and knock out the target.  In other words: baby step, baby step,  baby step, baby step, baby step, baby step, giant leap,  baby step,  etc.

Slow and steady may win the game, but taking well-timed, calculated risks can provide exponential returns.

Tension, Desire, Fear

We're going about cybersecurity all wrong.

I just read a blog post by the ever-inspiring Seth Godin, and this part made me think about what's missing from cybersecurity:

Alas, awareness is not action.
Everyone reading this is aware that Peru is a country. But that doesn’t mean you’ve visited recently, or have plans to go soon.
Everyone reading this is aware that turnips are a root vegetable. But knowing they exist doesn’t mean you’re going to have them for dinner.
Awareness is important, but it is insufficient.
Action comes from tension, desire and fear. Action is the hard part.

By now, everyone in your organization has gotten the cybersecurity memo.  Everyone from the CEO to the person who maintains the grounds knows security is important, and want to do the right thing. It's condescending, maybe even counter-productive to treat our colleagues as though they've never heard about security.  Take it to the next level by building the right combination of tension, desire, and fear to inspire our organizations to execute on security.

Most of us security people have the fear part down pat: if you don't do all the security things I tell you to, something really bad is going to happen.  The problem is that we've probably been saying that for years, and nothing bad happened.  The wolf never came, and even if it did, the bite didn't hurt that badly, so everybody stopped listening to to the Little Security Boy.  We need to employ other strategies to inspire our leadership and colleagues to action.

One way to create tension is to make it easier to do the right thing than it is to keep doing the same, wrong thing.   Try breaking the problem down into the smallest possible components.  Analyze the work you want done.  What is the logical first step?  What would this process look like if it were easy?  Identify the easy parts, the cheap parts, the fast parts. Once we've done a few small things, we can build on our success.  Remember that it took years for things get to where they are now, so it's naive to think we can fix them overnight.  What we can do is do something.  We must do something. Today.  Tomorrow.  Every day.  Start the ball rolling - if we can keep it rolling, pretty soon it will gain its own momentum.  First we create the tension by making the work seem easy.

When we think of security, the term desire doesn't exactly jump out. Desire is a positive emotion, and we all have plenty of it.  We desire to do a good job, to be recognized, to do the right thing. We desire less stress, less distraction, more wins.  Everybody knows things could be better, security-wise - they want them to be better.  But they don't know where to start until you create the tension by getting the ball rolling.  Making progress - any progress, even if all we've done is stop the bleeding - starts a virtuous cycle in which the team starts to want to do more. Let's celebrate the work that's been done, no matter how tiny, and try not to remind the team about the mountain of work that still needs to be done.  By focusing on the success, we create the desire to build on that success.

Let's stop talking to people as though they've never heard about cybersecurity.  Let's stop playing the fear card, and build tension to fuel the desire to start moving our organization toward a more secure place.