Chapter 2. Security Principles

The early bird gets the worm, but it's the second mouse that gets the cheese.

Steven Wright

Security is not the result of properly designed and developed software or systems. Rather, it is part of the process used throughout the entire software lifecycle, from design to development, testing, deployment, and obsolescence. Security should be considered before any design is contemplated and long before any code is written or circuits are wired. Too often, security is an afterthought. Developers go straight for the code or the bench because that is where their efforts can first be recognized and because that is considered the "cool stuff."

In this code first, think about it later mentality, the first step is to try to implement the core functionality. Now, we are not saying that following a rapid prototype methodology is wrong, quite the contrary. Performing up-front development to ensure that the technically challenging portions of the development are feasible has merit. However, in a rapid prototyping approach, after the prototype is completed, the final design is developed from scratch, and often the previous development work is discarded, either in whole or to a great extent. The practice we discourage is development in which developers begin expanding and retrofitting to add other features, such as multiplatform support, copy protection, or user interfaces, after functionality is in place. At this stage, some developers even think about scalability or security, although, unfortunately, this does not come until much later in too many cases. Using this latter approach, it is no wonder that software and electronic devices end up with many security vulnerabilities and that more time and money are spent on testing and patching than on the initial design and development.

The good news is, this does not have to be the case. In this text, we give developers, consumers, and managers the information necessary to understand and evaluate the security risks and vulnerabilities of any system, be it consumer applications, wireless devices, or wired networks. At the heart of all these systems and, we daresay, almost any device these days is the software. Rarely does an hour go by when we do not rely on some piece of software, either in an application or imbedded in firmware in a clock, coffeepot, streetlight, car ignition system, or home heating system. The list is endless.

With this great reliance on software, you would think that the process of developing and testing the software that goes into these products would be well-defined and refined. The truth is, software development practices stray far from this ideal. The consumer demand for more functionality at a lower cost is giving developers the false notion that they should not take the time to design the software properly, in favor of express coding and producing to meet delivery deadlines.

This logic is seriously flawed. By taking the time (however much or minimal it need be) to follow basic guidelines, developers can be assured that their products will work properly, safely, reliably, securely, faster, and cheaper than if they had begun the development process first. The ability to identify, evaluate, and mitigate the risks (security or otherwise) in a given system requires expert knowledge of both security and the system being evaluated. General knowledge enables you to ask intelligent questions to evaluate at least the high-level risks and, more importantly, to know when a situation requires the advice of a security expert.

We are not going to talk in depth about software security here. However, you should understand that software is the piece of any system that makes the whole puzzle either complete or incomplete. Also, software is usually the component that makes the system susceptible to security vulnerabilities and is the means, if not the cause, of exploiting hardware vulnerabilities. It will suffice to say that software is the most critical component of any system, and this criticality deserves appropriate consideration. Consumers are beginning to demand that software work as advertised, every time, anytime. The Addison-Wesley book Building Secure Software by John Viega and Gary McGraw covers this topic in detail. We recommend the book highly to anyone in the business of developing, using, or purchasing software that must work and must work as intended.