What to do before hackers attack your program

• By John K. Waters
• October 7, 2002

[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 development cycle.

''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 least-privilege
''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.''

5. Compartmentalize
''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 hard
''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 even yourself.''

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

Links:
For other Programmer Report articles, please go to http://www.adtmag.com/article.asp?id=6265