Home > Education, Enterprise Architecture, Security, Standards > The Security Development Lifecycle : Oil Change or Culture Change?

The Security Development Lifecycle : Oil Change or Culture Change?

June 1, 2007

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.

The Security Development Lifecycle : Oil Change or Culture Change?.

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.

 

  1. Phil Agcaoili
    January 29, 2009 at 10:50 pm

    Hello Dave.

    I just ran into your post and know first hand about the culture change required to make software security practical.

    If you can standardize and set your expectations for software security while remaining flexible to business needs, you can overcome the lack of development standards in your environment.

    We did this at Dell and it’s been paying off for us.

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: