The three-fold challenge of producing secure programs

Although software security is incredibly complex and difficult, most of the threats themselves are simple. See why security guru John McCormick views producing secure programs as a three-fold problem.

Although software security is incredibly complex and difficult, most of the threats themselves are simple. The problem with creating secure programs is three-fold.

First, programmers seldom have any security training or experience. Schools don’t teach security and, these days, most programmers start their development careers right out of college. I did too; but, when I was in college, I did security work for the university, then for a TV station, and finally for the computer company that employed me. This was when programming courses taught engineers and physicists FORTRAN, and modems weren't even invented. In fact, I don’t have a computer science degree because no schools offered one back then.

The second difficulty with producing secure programs is that a program may depend on a million lines of code—many of which the developers didn't write or even review. When I wrote my first programs in machine language (which was more than a decade before the invention of C), I wrote every single line of code, which wasn't a big challenge in those days. The first computer I wrote a program for was an IBM 1401 (a PDP-6 was my third or fourth computer).

Today, we have a far less secure environment with Web sites and VPNs; we're also working with much more complex tasks and using development platforms that hide 99 percent of the underlying processes from developers. This creates a massive challenge for developers who need to produce secure code. Bugs in compilers, which defeat the most careful security plans, make this task more difficult. For instance, at the beginning of 2003, I wrote about the way the GCC and other compilers’ optimizing processes defeat a careful programmer’s attempt to wipe a password from memory.

The third challenge facing software developers tasked with producing secure applications is that it only takes a single mistake to weaken a program's security. When you look at it this way, you can see why so many security experts state that it's impossible to create a totally secure program or operating system.

How much security is enough?
Determining how much security is enough depends on a number of factors, which include:
  • The intrinsic value of the application or the data it manages, or the network it resides on.
  • The exposure (i.e., Is this connected to the Internet? If so, how well is that connection firewalled and otherwise protected?).
  • The threat level. Data may be very valuable to a company, but it isn’t to anyone else. If the company isn’t really in the public eye, then the threat level is probably very low for a direct attack, although a random denial of service (DoS) or other malware attack is always possible.
  • The time value of the data. For example, financial data can be very perishable; one day it's vital to keep it secret, and the next day it's in a public 10K filed with the SEC.

To get good security, you have to engineer security in from the beginning; but these days it's still often an afterthought, and security features are often glued on to a nearly complete program.

Very few developers or companies are willing to put the required effort into creating a really secure program. The price of total security is unlimited, so there will always be compromises.

Software security is a relatively new concern. My first review for Byte in 1985 was of the book Software Validation Verification Testing and Documentation. When I look back today, it's surprising that it doesn’t have a chapter, section, or subsection that includes the word security.

Now I have dozens of software security titles on my bookshelves; some of them are even good. One book that will scare any developers who think their applications are secure is Ross Anderson’s Security Engineering: A Guide to Building Dependable Distributed Systems. The main value of this book is how Mr. Anderson lays out known and possible vulnerabilities regarding topics as varied as international banking, ATMs, hacking smart cards, and a “Tempest virus” that causes a computer to broadcast data wirelessly. (Note: This isn’t a coding book; it’s a worst-case-scenario book.)

Security is a process and, if a developer shortchanges any part of the process, then it flaws the entire project. Keep this in mind when you face this three-fold security challenge.

Editor's Picks