Security Program Success: 9 tips for ’09

 

By Michael Starks

2008 was a year like no other.  Then again, it was a year where not much had changed.  We learned about the Kaminsky DNS vulnerability through an unprecedented, coordinated advisory.  Systems not patched with MS08-067 became compromised with the Conficker worm.  PCI-compliant companies fell prey to attack. We even accused governments of sponsoring attacks against out national infrastructure.  Yet, despite the sensationalism, despite the potential for devastation on a large scale, our responses were largely, well, non-sensational.

As a student of human behavior, I have noticed patterns in the way we protect information.  We tend to follow the same rote actions and fall into the same habits.  Take, for example, the Kaminsky bug.  It was big news.  The DNS infrastructure was at stake.  The inevitable exploit was released.  Some companies patched and others decided to wait it out.  And then… nothing.  You hardly hear a word about it anymore.  Did everyone finally patch their systems?  Of course not.  

I observed three categories of response to this vulnerability, with these responses generally following other risks.

1. Those who did a true risk analysis and decided, based on that risk analysis, what to do.
2. Those who were moved emotionally by the audacity of the possible impact, patched.  
3. Those who felt as if they are unlikely to be attacked, or had higher priorities, waited it out.

People in the first category realized that emotional responses can’t always be trusted and sometimes only an objective process can bring things into perspective.  People in the second category were sufficiently scared into action, regardless of the true potential for compromise.  People in the third category made emotional decisions based on an immediate perceived lack of risk.  And if that risk didn’t materialize quickly, it was forgotten.  If these categories are generally true, then two out of three people made an emotional response to a perceived risk.  In other words, most of us wing it.

Although emotional responses to risk can cloud judgment, understanding human behavior is an important part of your security program  I’m not going to tell you how to respond to risk; rather, let’s focus on those things security programs usually lack: an understanding of how humans behave. How we can use that knowledge to get things done?  Here’s 9 tips for ’09:

1. Make it easier. 

Make it as easy as possibly, but no more.  Make it easy for you, for management, and for end users.  Easy things have appeal.  Complex things evoke pushback and negative reaction.  One of the first questions you should be asking in designing a security solution or response is: how can I make this easy?  The last question should be: how can I make this easier the next time?

2. Be approachable. 

I’ll be the first to admit that this isn’t easy for us technical types.  We generally like to control our environment.  We’re used to working with machines, not people.  But security programs are run by and affect, people.  So it makes sense to be a nice guy or gal.  When you’re approachable, people want to talk to you about the issues they face.  When they do that, you have an opportunity to help them by finding a secure solution to their problem.

3. Go beyond the corporate mandate. 

People generally don’t ask to be secure.  They just expect it as a condition of their work.  But that doesn’t mean they have no security concerns.  It is my experience that many want to be involved.  They want to do the right thing and be rewarded for it.  But corporate security is full of boring policies and procedures that no one wants to read.  When you give them something they can use personally, such as ways to prevent identity theft, they’re often willing to take some medicine with the sugar.

4. Toot your own horn. 

When a security countermeasure has protected the business, let people know.  Security is hard enough to justify, so make sure others know about successes.  When it comes time to ask for money, having a list of successes will help justify the expenditure.  This also takes a bit of the edge off the not-so-successful endeavors.

5. Consider the environment. 

How likely is your security measure to be accepted?  Does it make sense to install a man trap in a company with no AV?  Are your admins savvy enough to implement and maintain a network access control solution?  While risk should be the main motivator for these decisions, it’s important to consider the practical considerations.  Shoot high, but not so high that you lose sight of the ball.

6. Go for the small wins, first. 

Nothing builds on success like success.  If you have a big project coming up, make sure there is some easy stuff up front.  It will motivate and encourage people, and take away some of the trepidation.  Being successful makes people feel good.  When people feel good it’s easier to work with them and they do better work.

7. Reward good behavior.

Pop quiz: name three sanctions in your security program, then name three rewards.  What?  You write people up, fire them and threaten them with arrest, but you can’t hand out some movie tickets once in awhile?  Make people feel good and they’re more likely to repeat that behavior.

8. Learn from the past.

None of us are perfect.  Our security programs have successes and failures, but with the failures come an opportunity to figure out what went wrong.  Use these valuable opportunities to fine-tune your program.  Use them to become more approachable, toot your own horn and reward good behavior–you get the idea.

9. Consider the big picture.

Take a step back every once in awhile to think about the program, as a whole.  Is it accomplishing the objectives you set for it?  Are you caught in the trap of fixing problems the industry says you must fix?  Are you spending time mitigating the MD5 collision problem when you don’t have patch management working?  By looking at the big picture, you can get a better feel as to where your limited resources are most effectively spent.  

Security programs are all about people.  We often say that it’s about people, process and technology, but it’s the people who must implement process and technology.  Understand people and you will understand how to protect information.