Information Security: How Does Your Organization Fail?

Welcome ISC readers! While you're here, you may find our other articles on the security mentality interesting:

• The Scary Security Guy
• Bruce Schneier: Inside The Twisted Mind of a Security Professional

Our original article:

How does your organization fail at information security? The ISC's Lenny Zeltser breaks down many of the common failures in information security organizations - many of these are familiar.

A few of my favorites, with some commentary:

• Create security policies you cannot enforce. Or enforce security policies that make no sense, or are so egregiously bad that even your own security staff won't follow them.
  
• Assume that being compliant means you're secure. This is particularly common in organizations that have recently implemented PCI-DSS security requirements.
  
• Hide from the auditors - or better, provide incomplete information, or simply don't provide information at all!
• Let your anti-virus, IDS, and other security tools run on "auto-pilot." A common trap for understaffed organizations that do have funding for hardware or software is to buy solutions, but to then discover that they don't have enough time to maintain them. Increasing the number of security solutions, but not the time allocated to maintenance is a deadly trap for security.
• Make someone responsible for managing risk, but don't give the person any power to make decisions. This often makes system administrators unhappy - they're told that they're responsible for the systems and their security, but are told that they must provide any services that their clients desire. They're left with all of the responsibility, and none of the rights.
• Assume you don't have to worry about security, because your company is too small or insignificant. One of the worst threats I've seen to smaller organizations, or those with data that they perceive as unimportant. I ask "The question is not 'is your data important to them', it is 'Is your data important to you?'. If it isn't, then why are you in business, or why do you keep it?
• And finally, Dr. No syndrome: "Say "no" whenever asked to approve a request." One of the fastest ways to fail is to be seen as a hindrance, rather than a partner. Yes, information security must know how to say no, but no is not the default answer.

As organizations mature, the mistakes they make tend to change. As policies and procedures become more ingrained, the mistakes made due to lack of knowledge or worries about security are likely to develop into issues with complexity, familiarity, or organizational habit.

The Security Mentality: Scary Security Guy?

I act as a stand-in instructor for an undergraduate security class a couple of times a year. Typically, I teach an hour or so about physical security, and lecture in coordination with the campus data center manager about data center security and operational security at the university. I tell a number of stories, and offer examples of how security design is done on campuses, as well as in the students' every day lives.

Each time I lecture, I ask the instructor about the feedback from the class. Typically, there is positive feedback, and often there is something interesting that the students will pick up on. The most recent class, however, had something new to say:

"Your friend is scary".

I'm used to scaring our datacenter manager - the security analyst's approach to systems is something I've talked about before. He knows that I analyze based on risk, and that while I may enumerate a wide variety of risks, that I'll work with him on the most plausible, and dangerous risks. The students, however, aren't used to assessing risk in the same manner, and don't think like analysts would.

This points out a problem: people rarely react well to things that are scary, and we don't want to be seen as paranoids. How can we avoid being the scary security analyst?

In general, we need to do three things:

1. Choose our battles wisely, and avoid being Chicken Little.
2. Be helpful, even when describing risk: cast the risk as an opportunity, or offer useful assistance and guidance.
3. Teach security mentality when possible.

Bruce Schneier: Inside the Twisted Mind of a Security Professional

Bruce Schneier's commentary on Wired about how security professionals think is a good read - and a great opportunity. Those of us in the industry often hear statements such as "Wow, I'm glad you're on our side" or "That's pretty evil!" when we make suggestions of how to break a system. Bruce says:

"This kind of thinking is not natural for most people. It's not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don't have to exploit the vulnerabilities you find, but if you don't see the world that way, you'll never notice most security problems."

Bruce's thoughts on this closely match my own - we are, in some ways, engineers of failure. Where others look to make systems work, we seek to stress and test them to the breaking point. The mindset is often difficult to escape - the switch is always on.

When I'm at my local credit union branch, I'm watching to see how they handle my transaction, and how security is set up inside. I look for flaws everywhere - from simple issues like not locking doors to complex issues with data and programming. I know that I check security automatically, and that I analyze almost any system I'm faced with to find flaws or opportunities for exploit.

Since we're security professionals, and we'd like to make other people more aware, we're faced with the question: can we teach the security mindset? Bruce's contention is that it isn't trivial:

"I've often speculated about how much of this is innate, and how much is teachable. In general, I think it's a particular way of looking at the world, and that it's far easier to teach someone domain expertise -- cryptography or software security or safecracking or document forgery -- than it is to teach someone a security mindset."

So, if it isn't trivial, how do we do it? Can we teach the rudiments of the security mindset in a way that makes it available and open to the layman? I believe we can. Will they be effective security analysts overnight? Of course not - there's a degree of technical knowledge and understanding that we can't instill easily. The analytical mindset is, however, something we can plant the seeds for. Just a little crack in the normal mindset that accepts systems, and that instead looks for issues is all we need!

Here are a few ideas that you can use to prompt people in your organization to adopt the security mindset:

1. Challenge them to think like a bank robber when they next do their banking. Ask if they pay attention to security cameras, how they identify themselves, and if the cashier has money out and visible.
2. Get them interested in how a system they are involved with can break. Web developers often delight in breaking an application if you show them how, and system administrators are tickled to learn how to break into a machine - if it isn't theirs! Find something that the person works with every day, and show them how the system can be broken.
3. Make opportunities to ask questions and to test systems available, and encourage your staff to do so. I've had the opportunity to lecture college classes on physical security and you can help foster the moment when the light comes on through simple means - tell stories, point out issues and fixes, and then ask simple questions. You'll be surprised at how the pace picks up once one person answers.
   

How do you plant the seeds of the security mindset?