The Security Development Lifecycle : Oil Change or Culture Change?
Dave Ladd provides an interesting picture of how architecting (and “selling” security) to the CxO’s isn’t so much about promoting technology, but promoting culture change.
I have worked on security and privacy initiatives at Microsoft for a number of years, but it wasn’t until I came to the Security Engineering group to work on the Security Development Lifecycle that I realized I don’t actually work on security. To be clear, I do many of the tasks that one might associate with security – look at bugs, evaluate tools, provide guidance and the like – but it’s more accurate to say that I (along with everyone else in Security Engineering and Communications) am in the culture change business.
This is very interesting concept, especially in my field of education. Many of our vendors, peer districts, and such are baffled by our rigerous standards for security—both in our development and our infrastructure. I’ve spoken with only a handful of districts that place security at the level that it is a strategy—not a byproduct—of their overall technology architecture.
Why is that? First off, I believe a lot of that comes from our CIO’s passion for security and doing things “right.” FERPA and privacy are at the forefront of concern—and avoiding the courtroom for any mishaps. Our applications must not only be protected from the deviant of the Internet, but from the 50,000 students and 10,000 staff members who are using our systems. Are they all “out to get us”? Nah, not usually—but typically the most innocent of individuals is the first to find the biggest security hole.
Second is resources. Technology is highly valued in our environment and has almost infinite funding given proper documentation and a good sales pitch to the executive levels and board. Because of that, our physical and software infrastructures have many of the latest and greatest gizmos, gadgets, and such to protect our information.
What’s missing? For us, it’s standardization in both development and implementation. We’re still struggling with fully grasping what it means to write “secure” code; however, this changes with every day as we become more adept at development and, as most, learn from our mistakes.