Contents: The -ilities The penetrate-and-patch approach is bad The root of all security problems What to expect in future columns The fractal world of hackers and crackers Resources About the authors Rate this article Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Gary McGraw, Reliable Software Technologies
John Viega, Reliable Software Technologies

01 Sep 1999

Welcome to our new "Security for developers" column! This is where you'll find in-depth coverage of security issues ranging from how to apply common security technologies, to writing more secure code yourself. Our ultimate goal is to help you stamp out insecure code without recourse to the "penetrate-and-patch" approach, and to have some fun in the process. Our first column introduces you to our philosophy of security, and explains why we're focusing exclusively on software security issues facing developers.

As businesses rush to embrace e-commerce, security stops being a minor detail and starts to carry some serious weight. But because most computer users don't know very much about security, a majority of the words devoted to computer security cover basic technology issues such as what firewalls are, when to use the DES encryption algorithm, or which anti-virus product is best. The rest of the literature tends to focus on the "hot topic" of the day, such as BackOffice 2000 bugs or the Melissa virus. While these topics are important to users, our column is going to focus instead on security issues facing developers.

Many good resources for security-related news and overviews already exist. We won't cover topics in security that everyone else is covering, or has already flogged to death. Instead, we're going to focus on how to develop secure applications. For example, many popular press articles deal with cryptography: what it is, and where, when, and how to use it. In this column, because we'll be looking at cryptography from the developer's perspective, you'll learn when, why, and how to incorporate it into your applications.

As a developer you're probably largely responsible for ensuring the security of the systems you write. Especially in today's world where most applications are either networked or have to coexist with programs that are networked, you must pay close attention to security throughout development. Many developers are aware of designing for security, but few know how to go about it. It's difficult to find good resources on how to write secure applications. Tips seem to spread by word of mouth, but few developers know more than a couple of them. Most developers we talk to admit to knowing little about security; almost all want to know enough to be confident that their programs are secure.

Our aim with this column is to arm you, the developer, with the know-how you need to be able to create secure systems. Yes, developers working on security-related products such as firewalls, intrusion detection systems, and secure Web servers will find this column useful. But more than that, developers of any software will benefit from this material. You don't have to be writing security software to be writing software that needs to be secure. Most of today's software is designed to interact on the Net somehow, and as soon as the Net enters the picture, security looms large.

With this column we also intend to help developers become amateur security analysts. Perhaps not surprisingly, many of the things developers need to know when they are creating secure code also turn out to be relevant to security analysts. Security is always harder than it sounds. When you are creating a security-critical system, an extra pair of eyes often helps, especially if the eyes are alert to real security risks.

The -ilities
Is security a feature that can be added on to an existing system? Is it a static property of software that remains the same no matter what environment the code is placed in? The answer to these questions is an emphatic no.

Contrary to what many purveyors of shrink-wrapped consumerware may believe, effective security cannot be bolted onto the side of a system after it is finished. Security is a system-wide emergent property of a software system. Thus, software should be designed from the very beginning with security in mind.

Security is like safety, dependability, reliability, or any other software -ility. Just as it is not possible to take an unreliable system, add a "reliability" module to it and hope to get bug-free software, it's not possible to add security to an application as if security were just another feature.

Security is a behavioral property of a complete system in a particular environment. In fact, security is so dependent on environment that it is entirely possible to take a system that is completely secure when implemented on a proprietary network, place it on the Internet, and end up with an easy-to-compromise disaster. (You've no doubt seen this happen.)

The penetrate-and-patch approach is bad
Many well-known software vendors don't seem to understand that security is not an add-on feature. They continue to design and create products at alarming rates (mostly due to the Internet time phenomenon), with little attention paid to security. They start to worry about security only after their product has been publicly (and often spectacularly) compromised by someone. And then they rush out a patch instead of realizing that incorporating security from the start might be a better idea.

This sort of approach won't do in e-commerce applications. The problems include:

• Developers can patch only those problems that they know about. Attackers may find problems that they never report to developers.
• Patches often go unapplied, as system administrators tend to be overworked, and often do not wish to make changes to a system that "works." And sometimes administrators aren't even aware of an important patch that should be applied to their system.
• Patches are rushed out as a result of market pressures on vendors, and often introduce new problems.
• Patches fix only the symptom of a problem; they do nothing to address the underlying cause.

Our goal is to help you avoid the desperation of trying to fix to a problem that is being actively exploited by attackers. In simple economic terms, finding and removing bugs in a software system before its release is orders of magnitude cheaper and more effective that trying to fix a system after release. By designing a system for security, carefully implementing the system, and testing the system extensively before release, you can eliminate these problems and develop a truly secure system that doesn't rely on patches.

The root of all security problems
Simply put, software is at the root of all common computer security problems. If your software misbehaves, you may be faced with reliability problems, availability problems, safety problems, and security problems. Compounding the security problems may be the fact that some bad guy is actively trying to make your software misbehave.

"Crackers," or bad guys who exploit security holes, don't create the holes; they simply exploit them, and often widely distribute their exploits as scripts. (By the way, the difference between crackers and hackers is that crackers break stuff, and hackers write excellent code. See "The fractal world of hackers and crackers" later in this article.)

Crackers and hackers aside, security holes and vulnerabilities are the result of bad software design and implementation. To win the war against crummy software, watch this column for information about common mistakes, and good ideas that can help you write more secure code.

What to expect in future columns
We'll cover four general areas:

• Security assurance
• Writing secure code
• Security testing techniques
• Applying common security technologies

Security assurance
In our next column, we'll introduce a risk analysis methodology that is far more effective than the "penetrate-and-patch" approach. In future columns, we'll tackle topics such as: how to perform a risk analysis, the importance of and difference between security testing and traditional functional testing, and how to think like a bad guy.

Writing secure code
Most security bugs stem from a small set of root causes. In future columns, we'll alert you to the major root causes -- such as buffer overflow problems and race conditions -- so that you can avoid these traps. We'll also discuss less-common attacks -- such as man-in-the-middle attacks -- that you can avoid with defensive programming.

We'll also cover important programming language issues that can impact the security of your code, such as why type systems matter, why Java beats the heck out of C, and what language-based encapsulation is. We'll also take on distributed systems and their impact on security, covering CORBA, COM, and EJB security concerns.

Security testing techniques
Security testing is a good idea -- especially since the bad guys tend to do it -- but few good free or commercial tools are available. We'll help you make the most of what tools are available, and also show you how to apply testing techniques without tools. One technique, static analysis, involves looking at code for potential vulnerabilities without actually running the code. Another technique, dynamic analysis, involves testing code by actually running it. Both testing techniques have their place in a developer's toolkit. We'll help you figure out when to apply which.

Applying common security technologies
A common misconception among many system architects is that securing a system boils down to firewalls and cryptography. In future columns, we'll explain why security is not cryptography, why cryptography is harder than it sounds, and why firewalls and proxies are a pain.

Mobile code raises a raft of security issues. We'll explain why mobile code security is important and what to expect in future systems. We'll also explain how sandboxing (a common code encapsulation approach) works, and why it is harder than it sounds. We'll cover code signing, which has picked up a lot of steam recently, especially in the Java 2 world.

Finally, we'll explain how to set up burglar alarms in your own applications, and how modern approaches to intrusion detection can help.

The fractal world of hackers and crackers
We admit it: we are hackers. But don't break out the handcuffs yet; we don't run around breaking into machines, reading other people's e-mail, and erasing hard disks. In fact, we stay firmly on this side of the law (at least when it comes to computers).

The term "hacker" originally had a positive meaning. It sprang from the computer science culture at MIT in the late 1960s, where it was used as a badge of honor to refer to people who were exceptionally good at solving tricky problems through smart programming. For most people in the UNIX development community, the term refers to someone who is an excellent and enthusiastic programmer. Often, hackers like to tinker with things, and figure out how they work.

Software engineers, however, attach a slightly negative connotation to the term. They see a hacker as the programming world's equivalent of television's McGyver -- someone who can solve hard programming problems if given only a ball of fishing twine, a matchbook, and two sticks of gum. The notion software engineers have is not that hackers are malicious; rather it is that hackers cobble together ad hoc solutions that are marginally acceptable. Software engineers believe careful thought about software design should precede coding. They believe that hackers are developers who tend to wing it, instead of employing sound engineering principles.

Average people (including the press) tend to have the most negative perception: that a hacker is someone who maliciously tries to break software. By this definition, a person who breaks into your machine is a hacker. Needless to say, many hackers resent this definition. Do locksmiths become burglars just because they could break into our house if they wanted to do so? Of course not. But, we admit there are hackers who are malicious, and do break into other people's machines, and do erase disk drives. Thankfully, these individuals represent a very small minority of the expert programmers who consider themselves hackers.

In the mid-80s, hackers who disliked the negative connotations coined the term "cracker." A cracker is someone who breaks software for nefarious ends. Unfortunately, this term hasn't caught on outside of hacker circles. The press doesn't use it, and it didn't help that a recent movie about malicious programmers was titled "Hackers" (instead of "Crackers.").

So, just who are the crackers? We've implied that some crackers can be hackers. Indeed, a cracker who breaks software protection mechanisms so that pirate copies can be easily distributed warrants the hacker label as well. Removing such protection mechanisms takes a fair bit of skill. However, most crackers are not hackers -- they're just kids trying to break into other people's machines.

Some hackers who are interested in security may take a piece of software and try to break it just out of sheer curiosity. If they do break it, they won't do anything malicious; they will instead notify the author of the software, so that the problem can be fixed. If they don't tell the author in a reasonable way, then they can safely be labeled crackers. Fortunately, most people who find serious security flaws don't use their finds to do bad things.

At this point, you may wonder what skills crackers have. Doesn't it take significant skill to break software? Skill is indeed required to find a new vulnerability, but not to merely exploit a known vulnerability. Generally, crackers are people whose programming ability is confined to downloading, building, and running programs other people write. (Hackers often call this sort of cracker a "script kiddie.") Crackers go to a hacker site, such as www.rootshell.com, download a program that can be used to break onto a machine, and get the program to run. It doesn't take much skill (other than hitting return a few times). In our experience, these people tend to be teenage males going through a rebellious period. Despite the fact that such people tend to be relatively unskilled, they are still dangerous.

You may also wonder who wrote the programs these script kiddies use to break stuff. Hackers? If so, shouldn't those hackers be called crackers too? Yes, hackers tend to write most such programs. Some of those hackers even have malicious intent, and are crackers. However, many of these programs are made public by hackers who believe in the principle of "full disclosure." The basic idea behind this principle is that everyone will be encouraged to write more secure software if all security vulnerabilities in software are made public.

In the eyes of full-disclosure zealots, developers who look at other people's security problems can potentially avoid such problems in their own code. Often, simply trying to explain the gist of a security problem isn't enough to help a developer. Without a working example of what an attacker might do, the developer won't fully understand the problem. That's one good reason for full disclosure. Full disclosure also allows informed administrators to address problems in software before the software vendor gets around to releasing a patch.

Of course, there are plenty arguments against full disclosure, too. In the case of Java attack applets, for example, we have had great success getting vendors to respond to problems (and fix them quickly) without ever releasing an attack applet into the wild. Nonetheless, people without malicious intent sometimes do release working attack code on a regular basis, knowing that there is a potential for their code to be misused. These people often believe the benefits of full disclosure outweigh the risks. That's why we don't inherently call such people crackers.

Resources

• Securing Java. See especially Chapter 7, which gives some guidelines for writing more secure Java code.
  
  
• Hacker's Dictionary. Where Net jargon gets explained.
  
  
• Internet Gambling Flaw. The Software Security Group at Reliable Software Technologies recently made headlines with the discovery of a security flaw in online poker. This story gives you some idea of what the authors of this article do for fun.
  
  
• The developerWorks columns by Gary and John have been updated and expanded in the book Building Secure Software, which also includes plenty of new material. Pick up a copy today -- your users will thank you.
  

Rate this article This content was helpful to me: Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5) Comments?

developerWorks > Security >