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
- 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.