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
Saturday, February 6, 2010
Tuesday, January 26, 2010
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
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
Thursday, January 7, 2010
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
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
Wednesday, January 6, 2010
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.
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.
Tuesday, December 15, 2009
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
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
Tuesday, October 13, 2009
Which is Easier?
I am way behind on my security podcast listening and I just listened to an OWASP podcast that discussed Gunnar Peterson's post recommending the book Enterprise Application Architecture by Martin Fowler. A former manager who is now an enterprise architect thought it was a good book, but it was interesting to see it recommended by a security professional.
This raised the thought in my mind about whether it was easier for a developer to learn security or a security professional to learn development. I am definitely biased (since I come from a strong development background), but I think training a developer is easier. I have taught so many programming classes where people struggled with simple loops and conditional structures that I am convinced it takes a mindset to understand development.
I do have a hard time understanding how people can't understand it, since I took right too it, but I know not everyone finds it as straightforward as I did. It is like the struggles I had with chemistry lab in college. I did well, but I never could get the results within the "A" range (though I could ace the tests) no matter how much effort I put into it. Physical chemistry is not my strength. In the same way, some people struggle with understanding key programming concepts.
I did have some experience with system administration; including work on Mac, Windows and Unix, though I never worked as a sysadmin. Putting in your own ISDN line did take some technical chops, since it required so much manual configuration at the time, so perhaps I am not the "pure developer" I think.
Interesting question, though we probably need to focus on training developers on security regardless, since a lot more developers are out there. We don't have enough security people to go around to get really strong application security, if we can ever reach that goal as a society.
Brad
This raised the thought in my mind about whether it was easier for a developer to learn security or a security professional to learn development. I am definitely biased (since I come from a strong development background), but I think training a developer is easier. I have taught so many programming classes where people struggled with simple loops and conditional structures that I am convinced it takes a mindset to understand development.
I do have a hard time understanding how people can't understand it, since I took right too it, but I know not everyone finds it as straightforward as I did. It is like the struggles I had with chemistry lab in college. I did well, but I never could get the results within the "A" range (though I could ace the tests) no matter how much effort I put into it. Physical chemistry is not my strength. In the same way, some people struggle with understanding key programming concepts.
I did have some experience with system administration; including work on Mac, Windows and Unix, though I never worked as a sysadmin. Putting in your own ISDN line did take some technical chops, since it required so much manual configuration at the time, so perhaps I am not the "pure developer" I think.
Interesting question, though we probably need to focus on training developers on security regardless, since a lot more developers are out there. We don't have enough security people to go around to get really strong application security, if we can ever reach that goal as a society.
Brad
Friday, September 25, 2009
Independent Security Researcher
At the end of August I took a generous buyout package from my employer and I am now an independent security researcher, whatever that means. I am planning on focusing on development security, since that fits really well with my background, but I am also quite interested in compliance issues and I believe my PCI experience is worth using in the marketplace today.
I am not looking for anything specific now, enjoying a slightly longer break than I have had in some time, but I am now starting to dig into things. I plan on doing some work with OWASP in some manner, but let me know if you have an ideal opportunity.
I would love to get my PhD now, so also let me know if you know of a good place I could craft a unique program, learn some more, contribute and have fun. I am hoping to not relocate from the Dallas area anytime soon, but I am open to travel as needed.
Brad
I am not looking for anything specific now, enjoying a slightly longer break than I have had in some time, but I am now starting to dig into things. I plan on doing some work with OWASP in some manner, but let me know if you have an ideal opportunity.
I would love to get my PhD now, so also let me know if you know of a good place I could craft a unique program, learn some more, contribute and have fun. I am hoping to not relocate from the Dallas area anytime soon, but I am open to travel as needed.
Brad
Subscribe to:
Posts (Atom)
