Out of habit I got up at 6:30 AM and drove down to the LA Convention Center for an 8:30 talk. Of course the conference didn't start until 9:30. To make matters worse, the Press Room was supposed to open at 8:00, but it didn't. I gravitated to the nearest source of Ethernet and electrons, a small island of tables under the escalator, to find that four other members of the press had forgotten the last day's events didn't start at 8:30. PDC furnishes coffee, bagels and lox, and various other comestibles for all attendees, so none of us was actually deprived, and we developed a new sense of camaraderie from our experiences in our press room in exile.
There were no keynotes--plenary sessions--on Friday, but the most important was the Security Issues breakout. I know it was the most important because of the attendance. I'd no sooner got established in the room than Dan Spisak came in, and soon after Auri Rahimzadeh showed up. Most of the other leading computer press people were bunched up at the front of the room. Definitely an important session.
It opened with some history, about the DEC import team and the development of NT. NT was supposed to be more secure than previous editions of Windows, and one presumes it was; but that can be taken as a comment on just how bad previous versions of Windows were. I don't suppose Microsoft would agree with that. However, thus was born the Vulnerability Finder Ecology:
Microsoft releases software. Teams then look for vulnerabilities. If they find them they either tell Microsoft in hopes of being rewarded by Microsoft, or they publish either the vulnerability or some strong clues about it in hopes that some third party will reward them. There are variants including academic and peer recognition as reward, but the upshot is that not only are there bad guys looking for exploits, but a lot of smart people who don't have evil intentions. This ecology is stable and in place.
The main point of the symposium was to introduce programmers to the Security Development Lifecycle (SDL)--an almost universal mandatory process that Microsoft uses to develop its software now and it defines the security requirements and milestones for the software in question.
Microsoft's Michael Howard stated it bluntly: You need to embrace the SDL because "Writing software and then bug hunting does not scale". It's better to design against vulnerabilities in the first place. Not only does that work better, but it saves money.
Since developers can't predict future attacks or attack vectors, a new approach to secure software development is needed. The SDL has been introduced in other places, but there have been revisions as flaws in the model were found. One problem is that existing software design models for building in security require that developers have considerable experience in finding security vulnerabilities. This is not always realistic. Experienced security guys can be expensive, and many smaller companies can't afford them. The trick then is to devise tools that smart developers without a lot of security experience can use.
The major presentation on the Security Analysis presentation was by Michael Howard, the author, along with David LeBlanc and John Viega, of 19 Deadly Sins of Software Security (Osborne McGraw-Hill, 2005). Copies of the book were given to those who attended the symposium. I got mine autographed.
The talks given during the symposium went into a great deal about each of the steps of the SDL process and how to go about implementing them. Critical to the SDL process is that developers learn how to create data flow diagrams (DFD) of their applications. Without complete, proper DFDs the SDL process will be of no use to the developer because all the later work done relies on the completeness and correctness of the DFDs a developer makes. Otherwise it is possible to come to faulty conclusions as to what aspects of your application are prone to be attack targets. The primary reason behind having DFDs stems from the basic realization that most serious vulnerabilities require data of some nature to alter in some way. DFDs now also need to encompass privilege boundaries between the various parts of an application to help heuristically determine which aspect of your application is at highest risk to attack.
During his talk, Michael Howard said that developers would do well to learn about traditional security models like Bell-LaPadula or Clark-Wilson. Howard also had some suggested reading materials for developers interested in secure development like Matt Bishop's Computer Security: Art & Science (Addison-Wesley Professional, 2002) as well as Edward Amoroso's older Fundamentials of Computer Security Technology (Prentice Hall). Of course one would also do well to check out Howard's own books Writing Secure Code, Second Edition and 19 Deadly Sins of Software Security. Developers who wish to lean more about rapid threat modeling should also check out Peter Torr's MSDN blog about "Guerilla threat modeling" at http://blogs.msdn.com/ptorr/archive/category/2392.aspx
Microsoft also brought in customers in the process of implementing the SDL. One of those customers on hand was Australian bank Westpac, whose representative gave his impression of how the SDL was working and what external forces had compelled the bank to start using it. The best take away from their insight was that the SDL is best if done gradually. Trying to move from your current development model to SDL in one whole hog effort is most likely biting off more then your company can chew.
Other take away from the various speakers included some advice to be very wary of pushing the responsibility of your applications security onto the end users. As one speaker remarked, "Users don't make good trust decisions". This is certainly apparent from evidence of users who will click on popups claiming to be able to speed up your Internet connection or as one speaker put it "Click here to change the laws of physics".
Overall the security symposium was full of great information about how the SDL works and how to go about implementing it in your own organizations with a common message between all the speakers to make sure you have executive level support for an initiative like SDL. Furthermore, its vital that developers familiarize themselves with some of the better books out there covering computer security and its implications so they can make better informed judgments at design time and save themselves and their companies time and money by ending up with a fundamentally more secure and well designed product at the end of the day.
It's impossible to summarize these talks, and worse, a bad summary will lull people into a false sense of understanding. Security is a complex problem. There are many new tools, including pre-formed threat trees and threat models that inexperienced developers can apply. There are rules: "If the principle user of a potential feature will be the bad guys, remove the feature." Howard gave the example of the meeting scheduled to last two hours but was over in seven minutes because it became clear that the number one user of a feature would be hackers. Regular users would hardly know the feature was there. Remove the feature and let's meet again next week...
There was a lot more. I found out that what the Microsoft security analysis people call a "threat" is not what the intelligence community calls a threat, and if a security team has any old spooks on it, they'll have to change their mind set. So it goes.
And, of course, the primary requirement for writing secure software is management commitment. If the management attitude is "ship it!" no matter what, you'll always fail. Management needs to be convinced that insecure software costs money, in bug fixes, in updates, in technical support, and potentially in lawsuits despite the best disclaimers and non-warranty user agreements lawyers can write.
Our heads were still buzzing with security matters when we went down to the Press Room to write all this up. That was an experience: First they shut down the wireless net, but left the Ethernet connections. Then workmen came in to remove the walls. Eventually we found ourselves isolated at a table in the middle of an enormous room. Lights went out all around us.
We got the hint and went home. PDC was over.
Jerry Pournelle is science-fiction writer and DDJ columnist. Jerry can be contacted at [email protected].
