Here is my list of what I think Enterprise Security can and should do in 2009.
1. Educate yourself on state of the practice in software development
Spend as much time (or more) reading about software and data as reading Bruce Schneier and security. Specifically, security people should pick some good topics in software and data and follow up on them - some good places to start Martin Fowler, Pat Helland, and Kent Beck. if you want to be taken seriously by developers, you need to master this stuff before lecturing developers on how you think the so-called SDLC should work. Plus understanding the software development rabbit holes in your organization will help you craft more successful implementations.
Or as Steve Ballmer says,"Developers.Developers.Developers."
2. Eat lunch with developers
Take some of your security budget and eat lunch or drinks or coffee with some folks in development. People are the keys to solutions. Security people need to build good relationships with the software developers that need to carry the mail.
3. Learn about identity
One of the most frightening things of the last couple of years is that when I speak at security conferences and ask for hands on who knows about SAML or Cardspace only a few hands go up. Then when I speak at identity conferences, and ask who has heard of OWASP its like "Huh, wha?" Man that is scary. Identity is the basis of access control, if you don't understand identity then you don't understand your access control model. Rolling out security architectures on username and password in 2009 is lame. Pick a technology or two like SAML or Cardspace and drill down.
4. Build prescriptive patterns
If its in the policy, then there should be mechanisms that implement the policy otherwise remove it from the policy. If there are defined mechanisms then Information Security should make sure that pluggable patterns are there to be pulled off the shelf like Lego blocks to implement AAA, input validation, and other common patterns. I repeat, if you can't boil it down to a pattern that can be implemented at runtime, take it out of the policy - you are wasting people's time. No security doesn't have to write all this stuff but either find a library you like, "bless" an existing implementation as the new standard or shepherd your own development project (you will learn a lot). While we're at it - can we agree to stop writing access control from scratch? There are plenty of good libraries out there. Everyone always says "ohmygoshyoucantwriteyourowncryptodonchaknow!!!", but then what do they do? They protect the key(s) with some hand rolled access control foo. It makes no sense.
5. Dogfood it
Once you have some patterns. Build a lab, get a skeleton Hello World application for each of the patterns. Deploy and operate a lab with all the aforementioned patterns, ideally host an internal Information Security app(s) on this lab system like a wiki or internal blog or something. This will help enormously for the InfoSec team to empathize with two key groups - the people who have to use the security mechanisms and the people who people who have operate the security mechanisms. Once security does this its ok if you take a few more people out to lunch.
The overarching theme of this to do list is for Information Security to mature beyond simple diagnosis. I know it is fun and profitable for people to find problems, but we need to then associate prescriptions with those diagnoses and we need to know the knock on effects of what happens when the prescriptions are implemented - which ones are most cost effective, which ones show measurable changes, which ones drive new business opportunities. Runtime assessment is very valuable, its even more valuable when it drives better design. We need to get to design time.
Thanks. That's a great post. I'm a new programmer. Well not so much. I'm an excellent programmer. I just am really new to enterprise architecture. The kind of new where I literally know nothing except for MVC pattern and that's it.
Posted by: Nuovo | January 15, 2009 at 09:52 AM