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.