So at your organization security has a low priority. It basically gets done after all the other stuff is done, and then some. Management says security is important, but they don’t walk the walk. Are they doing this on purpose? Is management lying when they say security is important? Or is there something else going on?
I’m inclined to believe managers that say that they think that security is important. Just like people who want to lose weight and excercise more, say they really want to, but many times don’t achieve much in that field.
Enter “Switch” by Dan and Chip Heath, a book about change. Not just change in other people. It’s equally applicable to yourself. If you think you and other people very rationally choose not to do security, this book might be an interesting one for you. The authors basically say that our hearts and minds often don’t agree about change. We want one thing, but do the other.
The authors borrowed the metaphor of the Rider and the Elephant from the book “The Happiness Hypothesis”. It’s about a Rider on the back of an Elephant. Herein the Rider, our rational and concious mind, directs the Elephant where it wants to go, but the Rider is much, much weaker than the Elephant. The Elephant is our unconcious mind in this metaphor. The Rider can’t control the Elephant by force. He needs to motivate the Elephant.
So if you want change, there are three broad strategies:
- Direct the Rider. The Rider is very logical and can become analytical without getting to action. You need to point the Rider to a clear destination.
- Motivate the Elephant. This is about finding the feeling why change is necessary. It is also very useful to show the Elephant that the necessary change is smaller than it thinks.
- Shape the path. Many change problems are actually situational problems. We think that people don’t want to change, but changing – for example the environment – can result in a radical different behaviour.
Direct the Rider
There are generally three ways of directing the Rider:
- Follow the bright spots.
- Script the critical moves.
- Point to the destination.
So you are a DBA for a list of Oracle databases and Oracle Fusion Middleware environments and there are lots of things to do, security wise. A security analysis tool told that your databases have 11,493 security issues ranging from schema owners with DBA roles, the sofware was never patched, lots of dangerous DBMS_% packages have been granted to PUBLIC and a lot of default users have weak passwords. And the time to solve this has always been target date 1 year from now.
Following the bright spots
We humans have a tendency to see the negative more than the positive. When you want change, you can’t dwell on the things that don’t work. It’s far more effective to look for things that, despite the odds, have worked out really well: the bright spots.
“Following the bright spots” is an excercise in finding things that have worked, rather than all the stuff that must be done and how not compliant the whole situation is. Maybe you never got permission to upgrade the Oracle software, but the Linux admins always manage to apply the latest patches within 2 weeks. Why are they able to do this? What is their approach? Or are the application admins much further in securing their environment? Or do you know people at other companies in simular situations that managed to bridge an enormous gap despite obstacles? Can you invite them to the next meeting?
Understand that your brain might still work to find out why this won’t work here. People have been able to reach 2.2 million people in Vietnam in the 1990s to fight malnutrition, based on the local “bright spots”. You could give it a try.
Scripting the critical moves
I cannot overstate how important it is to describe as clearly as you can what the desired outcome is of what you are trying to do. “We need to make the Oracle environment more secure”, is not a clear outcome. The Rider doesn’t know what he has to do now and will often get paralysed, not doing anything. So what is? You need to script the critical moves. You need to be very clear about what you are going to do first and what steps have to wait.
In Switch there is an example of the privatization of the Brazilian railways in 1995. Previous administrations had invested very little in the railways, so basically it was a mess, with 50% of bridges needing repair. When America Latina Logistica (ALL) took over the southern lines, they didn’t have enough cash to repair even a fraction of the problems. ALL needed clear rules how to go on:
- Only invest in projects that allow revenue in short term.
- The best solution is the one that costs the least money up front – even if it will cost more in the long term.
- Options to solve a problem quickly are preferred to slower options that will provide superior long term fixes.
- Reusing or recycling materials is better than acquiring new materials.
Now, whatever you feel about their choices, it is very clear. Very little wiggle room here. And while the company had to reject important contracts for transporting grain (because they didn’t have enough locomotivs), after three years they made a profit (whether they used this to solve the railway problems, the book doesn’t say.)
Your unclimbable mountain of vulnerabilities might need a similar approach. For example:
- First solve all issues for which we don’t need management approval. Even if we leave bigger security holes open.
- When we do need management approval, we only do things that need less than 1 hour downtime.
- We will skip patching until at least next year.
Another approach might be to choose to only apply new security rules to newly delivered systems. The idea is that with time more systems are up to code and when the time comes to solve the issues on the older systems, the work on this is smaller.
Point to the destination
We already saw the Rider’s greatest weakness: to get lost in analysis. He will want more data, all the while not doing anything. To solve this, you need to point to a clear and vivid destination. This replaces the Rider’s analysis with figuring out how to do it.
You might think of SMART goals: specific, measurable, relevant and timely. SMART goals are fine in a steady-state, but for change situations you need more than that. You need a goal with emotion. A goal that “hits you in the gut”. You need a BHAG: Big Hairy Audacious Goal.
An example of a BHAG is John F. Kennedy’s speech to land a man on the moon before the end of the decade and to bring him back safely. It was certainly audacious at the time and also very clear. If a man lands on the moon only in 1971, if the man lands on the moon in 1969, but cannot get back, or if NASA had decided it rather wanted a space station in 1969, the job would not have been done.
In a security mindset, what might a Big Hairy Audacious Goal look like? It could be something like “from next year on, no more insecure applications”. This might not be in your power alone, but it could certainly something you propose to the IT team as a whole.
Another possible one: “From September on our vulnerability scanning software will only show Level 3 and lesser vulnerabilities”. Very clear and very little wiggle room (which is important), allthough you’re in the hands of how this vulnerability scanning software defines Level 1 and 2 problems.
You could also say: “From September on no more weak passwords, no more excessive privileges and no lagging more than a month behind the latest patchset.” It’s clear, but what excessive privileges exactly mean is still open for interpretation.
If you know better ones, please tell me so in the comments.
I’ll write about motivating the Elephant and Shaping the Path in an upcoming blogpost.
If you rather want to listen to the blogpost: listen to or download the audio version here: