Is It Ever Too Early To Teach Security?

About 25 years ago, back in the mini-computer era, I was a developer in an operating system group. My team was working on a brand new print and batch spooling system. We were creating a system with a lot more power and flexibility than the previous system. Plus we were working with an operating system that was making changes to the security/privilege model. Very early on in the design process we started talking about system security. Because things were getting more complex we wanted to make sure that we didn't open new security holes. And of course plugging any existing ones was a thought as well.

Security was part of the plan from the beginning. We convinced the core OS team to add some features just for us to make sure that communication was more reliable and to make it less easy to fake credentials. That benefited others as well of course and I think ultimately made the whole OS more secure. But the main point is that we designed security in from the start. It wasn't something that we retrofitted or added on later as part of a separate security initiative.

I've been out of the OS development business for a long time now but security of applications is something that is still near and dear to my heart. It's hard to teach in early computer science classes though because the projects are, for the most part, small, simple and artificial. But I still think that it is something that should be talked about and hopefully thought about.

Along those lines I came across some useful and free information about Microsoft's Security Development Lifecycle. Michael Howard, Principal Security Program Manager, has written a short article titled "Building Security into Windows Vista and the Microsoft Culture" that talks about the cultural change that had to be made at Microsoft and that has to be made at many places to really get security right.

Related to this is a new document called "Security Development Lifecycle Guidance" that is available as a free download (registration is optional but recommended if you're really interested in this topic.) I think the introduction would be a reasonable read and kick off for discussion with a class of students. If you are in the target audience for the book (policy makers and software development organizations) by all means you'll want to read it all.