Patient Gardening

I was pulling weeds in my garden last weekend, and it struck me that there are a lot of parallels between gardening and cybersecurity.  I’m always overwhelmed when I first look at the garden and see all the weeds and the disorder. I feel really discouraged, because I don’t know where to begin.  My first impulse is to attack everything at once, but every time I take that approach, I never feel like I’ve made any progress when I knock off for the day.  Over the years, I’ve developed a couple of strategies that may help you bring your garden in order, too.

Vertical strategy - Pick a weed

Decide on a single weed, and eradicate it from your garden.  I usually start with dandelions. Dandelions are a good choice from a risk perspective -  a single plant can produce up to 15,000 seeds. Their distinctive yellow flowers make them easy to spot.  But dandelions have deep roots, and if you don't get the whole root, it will sprout again and be even harder to pull next time. I invested in a special tool to loosen the soil so I can get the whole root Since I'm only targeting, it’s pretty easy just to walk around the yard with the tool and pull every dandelion I spot. After about 10 plant, I develop a technique and get really good at uprooting dandelions.  I usually don’t need the tool for the next type of weed I choose, so I set it aside once I've gotten all the dandelions. It’s really gratifying to see that the dandelions completely eliminated from my property!  Now that I've gotten them down to zero, it will be really easy to spot - and eradicate - any new dandelions that spring up.  

Horizontal strategy - Pick a spot

Another way to go about weeding is to pick a small area - say your lettuce patch - and pull all the weeds in that small patch.  This technique is slightly more zen - you may be able to even sit down for a spell and pull all the weeds within reach.  It’s more immediately gratifying to completely purge a patch of weeds down to nothing but soil, and it allows you to get your priority areas to zero-defects.  Once you’ve cleared all the weeds, it’s also easy to keep clean - just pull up anything that pokes through the soil.

The great thing about pulling weeds is that it doesn’t have to be a big project if I don't want it to.  I don’t need a plan to be successful,  but I do need a strategy.  It’s a group effort, and every little bit helps - I’ve persuaded each member of my family to pull  a couple of weeds on her way out the door (assuming there’s no quarantine). 

What are you doing to weed your garden?

Measuring Training

We security boffins love metrics.   We measure compliance, performance, response times, and roll them all up into pretty dashboards so we can document the efficacy of our programs.  Makes a lot of sense - why don't we do it for training?

Most organizations require all their users to undergo some form of cyber security awareness training, and most organizations squander their users' time and attention by trying to boil the ocean.

Rather than share practical skills for avoiding common online threat, the vast majority of security shops use their awareness training to test their colleagues on how well they can regurgitate the company security policy or jargon.  Under this model, there is no good way to quantify the effectiveness of the training, or to see which parts worked and which could use some improvement. More important, most of the training I've seen doesn't address real-world security issues that the organization is grappling with.  Instead, it deals mainly with policy and HR issues. Not only is it no fun to take, but it's impossible to know whether it does any good.

Instead of using a shotgun approach, what if you had your incident response team work with management to determine the issues behind the three or four most common real security incidents from the past year?  Things that can be counted, and are quantifiable in terms of cost, labor, and damage to reputation. Things like phishing, NSFW web surfing, and overly permissive file shares.

Now build a training module around each issue you selected. Explain the risks, what the problem looks like, and how to avoid and report it. Use anonymized, real-world case studies from your organization to illustrate the issue. Rather than bore them with acronyms and policy jargon, engage your students by talking about things they care about - like downtime, loss of privacy data and revenue.  This resonates: The reason the holiday bonus was smaller than usual was because we had to purchase Credit Monitoring for 10,000 customers whose data was stolen because of a phishing attack. 

At the end of the year, compare the number of incidents between the last two years.  If your training module is effective, the numbers around that incident category should have gone down.  If so, work with your incident response team to identify a new issue to target.  If you see the numbers for a particular incident type start to creep up again, you can rotate the corresponding module back into your training.

If, on the other hand, the numbers for a particular incident category aren't going down, or at least remaining static, that module may not be effective.  At this point, you have a couple of options:
Solicit feedback from your users as to how the module could have been more effective.
Try attacking a different issue. It could be that training just doesn't prevent that type of incident.

Over time, you will develop a library of training modules for all of your most painful security issues.  You can continue to expand and update them based on emerging threats.  And even if you don't like the results, you can still quantify the business value and ROI of cyber security awareness training, enabling your management to make informed business decisions about the program.

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.  

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?

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.