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.

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?