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.