The Value of Certifications

I see two basic camps in the security realm when it comes to certifications.

The first would include those with an alphabet soup behind their name. CISSP, CISM, CISA, GSEC, GIAC, GSE, CEH, CCNA, CCIE, etc. I suspect I could keep typing for days and not list them all. Organizations that promote these will definitely push that they add value and validate that the holder knows something of value to an organization and is worth more. This may or may not be true, but certifying organizations do make a substantial income on people maintaining their certifications, so they definitely have a vested interest in believing that certifications are valuable and promoting them.

I would note that I am not convinced that certifications are always a cash machine, but they do fund the employment of many people, so the amounts are significant. Those people are probably needed for solid certification programs. This means that large sums are involved in the process, whether or not those involved make a lot of money personally.

The other end of the spectrum argues that certifications are completely worthless and work experience is all that matters. They often look in disdain on those with certifications. They tend to view certifications as creating "paper tigers," people who can pass a test, but who don't really know much practically. I suspect having a certification is a bad thing if one of these people is in charge of the hiring process.

What spurred me thinking on this again was an OWASP podcast with Mark Curphy. (Yeah, I am a little behind - the show was from last July.) He expressed the second view and seemed to disdain certifications in general.

I am more in the middle of both camps and see merit in both positions. I have personally acquired many certifications because I felt like it, not because I wanted some letters to add to my name. Even though experience is still more valuable, I would rate my M.S. in C.S. from Illinois as more valuable than them all (along with a B.S. in C.S. from their Engineering College) as far more valuable, since it laid a firm groundwork for all the many things I have dug into.

That said, my certifications, especially the SANS ones I hold (GSEC, GCFW, GCIH, GCIA, GPCI) helped me really master the material in this area. My background is more in programming/development than system administration, so having to have studied the material for those courses has helped me absorb a lot more than I would have with just reading a book. Of course I need to put things to practice, but that is true of anything.

My main point would be to not worship certifications, but don't disparage them out of hand either. Don't get any if you don't see the need, but don't automatically assume someone with several is really incompetent either!

The Insider Threat to Drivers

This article shows that the human factor is always going to be a major factor in any overall security stance. A disgruntled downsized employee used a former coworker's account to access a system for tracking and disabling cars that they now use frequently at "buy here, pay here" auto sales places. A bunch of people had unworking cars until they reserved this. It kind of makes you concerned for what the future could hold as we place more and more computerized control devices in cars and other electronic equipment.

http://www.dailytech.com/Disgruntled+Former+Employee+Wirelessly+Bricks+100+Cars+in+Texas/article17918.htm

I am reminded of a recent Onstar commercial where they remotely disable a stolen car so the police can catch it. While that sounds great, what would happen if a disgruntled employee got access to that system? It is very important that we make sure companies with that kind of control have very secure development processes. In this case, making it harder for a single employee to disable so many vehicles so quickly would have been a reasonable development limitation and would have limited the possible damage in a case like this.

Sausage and Security Standards

Most of us have heard the statement that you never want to see 2 things being made: sausage or laws. Both are quite revolting when you get a close insight into the process.

I would probably add security standards to that list. I got to spend most of this week working with a standards group that was doing just that. This was my second time attending their meetings and while I found it very interesting, it is definitely a messy process.

People can very easily get on each others nerves in such an atmosphere, though I did find everyone remarkably cordial overall. Much of the week was outside my direct area of interest and the part that really fit my background seemed to get a bit bogged down in issues I was not as passionate about.

That said, I am still planning on attending the next meeting. I am working with a friend toward a valuable goal in this area and think it is both worth my time to go and a good part of my own learning process.

I do hope to be even more informed before my next meeting, though others have told me this is the normal pattern. The first few meetings you just listen and learn. Then, as you get more comfortable and can put more of the pieces together, you can be more involved in the debate/discussion/coordination.

Worth checking out if you are interested, but I will warn you that it can be boring! It can also be scary if you think of who the many good standards we have must have been made.... :)

Brad

More Secure with Age?

I was reading a column from CIO Insight magazine last night that made a very good point. The context was testing, but it applies to security as well. In Testing, Testing, John Parkinson discusses how complex systems are today and that this means that testing can never cover the entire system in the time allowed. His main point was that good practices up front are far more important than trying to find problems later.

This certainly applies to secure development as well. It is much better if we actively design systems to be secure than if we go through it later and try to test for all possible security vulnerabilities. Getting to this state is much harder than it sounds though, since most developers primarily focus on getting things to work, not giving much thought to making them secure, since that is often not even covered in the requirements. Developers will aim at what they are testing on and companies are only at the start of doing a good job integrating secure functionality as part of the requirements of new systems.

So far so good. This is the common message of those working in the secure development area today and it is even starting to take hold, though we have a long ways to go.

He made one good point that jumped out at me. He noted that we commonly think that code that has been around a long time is often more robust, since no problems have been found. This attitude is wrong though! Older code gets patched repeatedly during its life and those patches can have unexpected impacts on the system. Testing rarely covers as much of the system for changes than for a brand new system. Thus the older system is much more likely to have undiscovered problems.

The same is true with security. We think systems that have been around a long time and that have not been breached are secure, but all the ongoing changes are more likely to have caused security vulnerabilities we don't know about. Older systems are not necessarily more secure, even if we haven't found the problems yet!

This is certainly not a comforting thought, though it makes a lot of sense.

Brad

Making Security a Game

One of the things I enjoy doing is playing Euro games. These are games like The Settlers of Catan and Ticket to Ride (though the get more complex). These are generally fairly easy to learn, with rules closer to Monopoly than the older more complicated wargames I grew up with (from Avalon Hill, SPI and such). These games also almost always have good fiddly bits that make playing an enjoyable tactile as well as mental experience.

I have been thinking that this would be a great format to teach people about information security, especially the basic principles. While I have not had the dedicated time to think about this beyond some basic thought, figuring out how to make it fun an interesting, while keeping it accurate, is a big challenge.

I realize that someone else could take this and make their own game, but that would be great for me. If it is any good, I would be sure to buy it!

Otherwise, I am going to keep thinking about this and seeing what I can think up. Having experience with a many of the games on the site I linked to should give me some ideas on mechanics that might work, so I should just have to figure out how to put it all in a fun format that accomplishes my learning goal, hopefully without people realizing that is even a goal!

Brad

What Does It Mean to Be Secure?

That is a key question we must address in our attempts to seek security for the information we work with. Knowing where you are going or at least having a good idea what you are aiming at is an important part of knowing when you are there.

How many really have an idea of what they are aiming for in their information security programs? Of course "compliance" or "meeting outside requirements" is a powerful driver in some form for many. I haven't seen many, outside of information security professionals, who wanted to make things secure "because it was the right thing to do."

If that is the goal, then information security will be pushed aside once management thinks they have reached the checkoff. Even if the checkoff is not a spoken goal, other needs will push the priority of other actions, making the checkoff the goal in effect.

A better approach is to raise awareness, especially in management, of the value and therefore desirability for secure operations. While this will still not be a "get there and rest" goal, it will help keep the motivation for work up over the long run, rather than just lasting long enough to reach the compliance doorknob.

Yes, information security is a process, not a goal, but we all work toward goals, not processes. We need to make sure everyone has a better goal in mind if we want to keep the process going.

Getting Management to Understand the Principels of Information Security

I teach information security classes at the college level and one of the things that always comes up is the need to get management to understand the necessity and value of information security. At a root level, it is vitally important for management to understand the core principle - that information is an asset and needs to be protected as such.

I am convinced that many leaders have not really understood this principle. They often do more to protect the office furniture in their organization than the do the social security numbers of employees! While some may do this intentionally, I think most do it out of ignorance, since they don't really realize how valuable some information is.

While the cost of protecting that can get high, many simple things are completely "free." That would include not using SSNs (or the last 4 digits of an SSN) as a default password or reset code for an internal system, especially if it will be stored somewhere in plaintext.

I am on a quest to educate management in this, though I have to figure out how to get through to them. That is the $64,000 question, as they used to say (based on the old game show). How can you get an audience with them and then make them see the importance of the basics of securing information using terms and phrasing they can relate to and that is compelling.

Hopefully I can work more of that in my future efforts.

Brad