What to do before hackers attack your program
- By John K. Waters
[PROGRAMMERS REPORT, OCTOBER 8, 2002] -- Outside intruders gain the most attention when developing system security.
But according to Gary McGraw, CTO at Cigital, the greatest threat to computer
system security is already inside the firewall. ''The biggest security risk today
is the software you wrote yourself without thinking about security when you were
writing it,'' McGraw told Programmers' Report.
McGraw is the co-author of Building Secure Software: How to Avoid
Security Problems the Right Way (Addison-Wesley Professional, September
2001). Written with John Viega, CTO at Secure Software, the book admonishes
software developers to consider threats and vulnerabilities early in the
''Software really hasn't gotten any worse,'' McGraw explained. ''It's as flaky
as it ever was or as good, but the risk profile has changed. It used to be that,
as a developer, you didn't have to worry about crazy people feeding junk to your
program to see if they could cause it to fail.
''But exposure via the Internet and mobile code has made that a real problem,''
he continued, ''and one that developers have to understand. There's an awful lot
of software produced today, and almost all of it is destined to live on the 'Net
somewhere or be network-enabled. Network-enabled stuff has a different
operational risk profile.''
Real attackers compromise software, McGraw said. It's all about getting to
exploitable code, which ultimately puts the security onus on programmers who,
traditionally, aren't security minded. What's more, hardly an app is now alive
that has not had a patch, which McGraw calls ''exploiters' roadmaps.''
''A patch is the vendor saying, ''Our stuff is broken and here's how to exploit
it,'' he said. ''If you look at the data over the last 10 years about what
happens when a patch is released, you'll see that only a few people who have the
software ever apply the patch. Right after the patch is announced, script kiddie
tools appear that target the unpatched versions of the software. The
announcement is like a big, red sign over the hole.''
Developers need to become educated about security, McGraw said, and security
people need to become educated about development.
In their book, McGraw and Viega provide a starting point with 10 principles
for building secure software. ''The goal of these principles,'' they write, ''is to
identify and to highlight the most important objectives you [need to] keep in
mind when designing and building a secure system.''
Among these principles are:
1. Secure the weakest link
''Bad guys will
attack the weakest parts of your system ... good security practice dictates an
approach that identifies and strengthens weak links.''
2. Practice defense in depth
''Manage risk with diverse defensive
strategies, so that if one layer of defense turns out to be inadequate, another
layer ... prevents a full breach.''
3. Fail securely
''Failure is unavoidable ... What is avoidable is security
problems related to failure.''
4. Follow the principle of
''Only the minimum access
necessary to perform an operation should be granted, and that access should be
granted only for the minimum amount of time necessary.''
''Minimize the amount of damage that can be done to a
system by breaking up the system into as few units as possible while still
isolating code that has security privileges.''
6. Keep it simple
''Complexity increases the risk of problems. Avoid
complexity, and avoid problems.''
7. Promote privacy
''Promote privacy for your users, for your system, and
for your code.''
8. Remember that hiding secrets is
''Keeping 'secrets' secret in a
binary is incredibly difficult [and] even the most secure networks are often
amenable to insider attacks.''
9. Be reluctant to trust
''Be reluctant to extend trust ... Both clients
and servers get hacked ... Social engineering attacks are easy to launch against
unsuspecting customer support agents ... Sometimes it is prudent not to trust
10. Use you community resources
Don't 'follow the herd blindly,' but there
is strength in numbers. ''Repeated use without failure promotes trust. Public
scrutiny does as well.''
other Programmer Report articles, please go to http://www.adtmag.com/article.asp?id=6265
John K. Waters is a freelance writer based in Silicon Valley. He can be reached