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.

Count and Measure

Why do you count?

What do you count?
Do you want the thing you're counting to get bigger or smaller?
What is important to measure?
How do you measure it?
What do you measure against in order to know if the number is moving in the right direction in an absolute sense?

Things change: for example, if you're counting the number of machines that aren't configured up to your standard and you add a thousand new machines, would you expect the number of non-standard machines to go up or down?

Assuming the machines are brand new, you'd expect them to be released to the current spec, so you'd hope the count of non-standard machines to remain the same, while the proportion of non-standard machines to the total would go down.

Even though the proportion looks better, you're not allowed to call this a victory, because you haven't actually fixed anything.

Similarly, if the count of nonstandard devices goes up while youre releasing those 1000 new machines, you should stop.  Stop and figure out why your brand new machines aren't going out with the correct configuration.  Stop the bleeding.  Fix the process,  release the rest of the machines with the correct configurations.  Unless it's easy to wipe them and start over, it's usually a bad idea to try go back and do a special fix for the machines that already went out with the bad configs.  It's cheaper and easier to simply treat them the same way you are treating the misconfigured machines you already had.

The earlier in the lifecycle you can fix an issue, the cheaper and faster it is to fix.  So if you see bad work, stop and fix it right away.  Then figure out what to do with the broken stuff.

The only way you know something is broken is if you're measuring it.

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.  

Intelligence Test

If you were a nation-state, how would you test a rival state's intelligence system?  What if you fed them fake information, and then sat back and observed how quickly they reacted to it?  You could measure your own effectiveness at disinformation at the same time you measured their response time.  You'd also begin to understand how they react to different stimuli. Simply by forcing your adversary to react to non-existent issues would throw them off balance and create general malaise.

What if you made them question their tools? Got them to throw away perfectly good - maybe even best-of-breed - systems just because you were able to convince them they were no good, or had a bug?

Now, instead of moving forward, your rival is tied up replacing resources that work just fine - at a great cost in labor, cost, and time. All for nothing. They're operating at diminished capacity during the replacement, and may replaced something effective with something not-so-effective. And you've figured out what buttons to push to make them react, at virtually no cost.

Am I the only person who thinks this is a pretty efficient way to test an opponent's capabilities?

Are New Risks More Risky?

Technology is in a constant state of flux and transformation, and this trend drives and accelerates the depth and pace of change even more.  Tools and solutions - even programming languages - seem to obsolesce before they are even fully understood, much less deployed and secured. 
This pace can be overwhelming to cybersecurity practitioners, and I think we sometimes cite risk as a defense mechanism against change.
Are new solutions riskier?  If so, is it because they actually carry more inherent risk, or because we don't understand how they work?   Is something that we haven't used before less secure than something we have worked with before?  This shock of the new may be behind our perception of the risk of embracing emerging tech.  Security folks don't like disruption, because disruption, like pure chaos, is hard to model, and much of our practice relies on modeling and predictability.  Cutting edge technology shifts the axis, forcing us to rethink our security formulas.
Some of this discomfort is understandable, but consider that not too long ago, it was considered unthinkable that anyone would use her credit card to buy something on the Internet - too risky.  Amazon, ebay, and PayPal embraced that risk - and made billions of dollars - precisely because everyone else was afraid to jump into a risky business.  It was madness to put sensitive data on a LAN, because it couldn't be secured.  Now, a lot of our data is moving to the cloud on the open web.  Is it riskier?
I think the risks are just different, but the biggest risk is standing still.  Would it have been risky for Sears or K-Mart to move their businesses online? You bet it would have been!  But it turns out doing nothing was even more risky.  Instead of losing some data, they lost everything.
Technology is advancing - and disrupting - at an ever-accelerating pace.  Jump on the train, or risk getting left at the station.

Serving the People You Serve

How well are you serving the people you serve?

In a recent Akimbo podcast, Seth Godin asks four core marketing questions that I think apply to cybersecurity.

1. Who do we serve?

 I believe that in cybersecurity, we serve three different masters:

"The Customer" - is ultimately who we are trying to protect.  She funds our business.

"The Business" - signs our paychecks. Everything they do is supposedly for the customer. 

"The Regulators" - keep us honest.  They set the standards we have to apply to the technology The Business uses to serve The Customer.

We have a relationship with all three of these masters, and we have to earn their trust and stay in their good graces in order to be effective. 

2. What do the people we serve need?
It isn't your father's IT anymore.  Technology is moving to an "as a service" model.  Microservices, chatbots, automation, The Cloud, mobile, wireless, collaboration.  This raises a lot of red flags to those of us who grew up defending systems with clearly defined boundaries.  The Business demands innovative solutions because The Customer demands it.  And the competition is scratching their itch.  And new competitors, new disruptions, are cropping up every day. The people we serve want to be served in a different way, and if we don't do it, someone else will. We have to adapt in order to survive.  And we have to do it in a secure, accountable manner.

3. What do we own?
What assets do we already have?  How can we adapt them to serve our people's new needs?  Can we retool our existing systems? More important, can we reimagine the way we use our monitoring, our firewalls, our intrusion detection, our access and identity management, our logs?  Are there new security capabilities in the very disruptive technology that The Business wants to use to serve The Customer?  How can we leverage what we already have to scratch the new itch in a secure way?

4. What do we know?
How can we tweak what we already know to adapt to our people's new needs?  How do we apply our knowledge of defense in depth, of best practices, of monitoring and incident response to maintain our relevance, and more important, our customers' trust?

Our customers' needs, the technology to provide services, as well as our requirements, are changing faster than ever.  How well are you serving the people you serve?