Chapter 25. Managing the Development of Secure Systems
My own experience is that developers with a clean, expressive set of specific security requirements can build a very tight machine. They don't have to be security gurus, but they have to understand what they're trying to build and how it should work.
One of the most important problems we face today, as techniques and systems become more and more pervasive, is the risk of missing that fine, human point that may well make the difference between success and failure, fair and unfair, right and wrong ... no IBM computer has an education in the humanities.
Management is that for which there is no algorithm. Where there is an algorithm, it's administration.
So far we've discussed a great variety of security applications, techniques and concerns. If you're a working IT manager or consultant, paid to build a secure system, you will by now be looking for a systematic way to select protection aims and mechanisms. This brings us to the topics of system engineering, risk analysis and, finally, the secret sauce: how you manage a team to write secure code.
Business schools reckon that management training should be conducted largely through case histories, stiffened with focussed courses on basic topics such as law, economics and accounting. I have broadly followed their model in this book. We went over the fundamentals, such as protocols, access control and crypto, and then looked at a lot ...