Terminology: What do these words mean

Every field has its own terminology, and the computer security field is littered with acronyms and confusing words. These few definitions should help:

• An attacker (also called a cracker) is someone trying to make a program or computer do what it's specifically not supposed to do, such as breaking into a computer they don't own to obtain or change private data.
  
  
• A hacker is a computer expert or enthusiast. Not all attackers are hackers -- some attackers don't know anything about computers. Also, not all hackers are attackers -- many hackers write the programs that defend you! Media companies only concentrate on the hackers who attack computer systems rather than the defenders, so some people use the term "hacker" to mean only attacking hackers. However, if you think all hackers are attackers, you'll have a lot of trouble understanding many security articles, so I'll use the definition shown here.
  
  
• A flaw is a mistake in a program or in the way the program has been installed. Not all flaws relate to security.
  
  
• A vulnerability is a flaw that makes it possible for a program to fail to meet its security requirements.
  
  
• An exploit is a program that demonstrates or exploits the vulnerability.

Changing your mindset

The biggest challenge in learning how to write secure software is changing how you think about developing software. Here are a few points that should help:

• Paranoia is a virtue. Trust nothing until it has earned your trust. Don't assume your input obeys rules you're depending on; check it. Don't ignore error reports from libraries; often, you need to stop processing on an unexpected error. Don't assume that your program is bug free; limit what your program can do, so that bugs are less likely to become security flaws.
  
  
• Normal testing usually won't find security flaws. Most test approaches presume that users are trying to use the program to help them get some work done. Thus, tests will examine how programs work in "average" cases or some maximum values, presuming that users will work in some "random" or "useful" way. In contrast, security flaws often only show up with extremely bizarre values that traditional testing simply wouldn't check. Some developers write very poor code and hope to test it into being correct. That approach simply won't produce secure code, because you can't create enough tests to represent all the odd things an attacker can do.
  
  
• Gadgets (like firewalls) and technologies (like encryption) aren't enough.
  
  
• Identify and learn from past failures. It turns out that nearly all software vulnerabilities are caused by a relatively small set of common mistakes. If you learn what those mistakes are -- and how to avoid them -- your software will be far more secure. In fact, this column will concentrate on how to avoid common past mistakes so that you won't make the same ones.