- Introduction
- Developing the Policy
- Secure Development Rule #1: No Buffer Overflows
- Secure Development Rule #2: Check Status Returns
- Secure Development Rule #3: Use the Security Features of the System
- Secure Development Rule #4: Code Reviews
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Secure Development Rule #1: No Buffer Overflows
Recently, a friend (call him Mike) who manages several programming projects heard that his company's proprietary software failed for a client because of a buffer overflow condition. The failure caused problems that "should never happen," according to his programmers. When the problem was finally diagnosed—after three days of downtime—Mike issued a policy stating that developers will not be allowed to use functions that copy memory unbounded. First, since most of the custom programming was being written in C and C++, he ordered that functions like strcpy would no longer be used. In fact, he ordered all development to stop and the programmers to go through every program to find all unbounded memory copies and fix them. When they completed the examination of nearly one million lines of code, they made over 1,000 changes. Over 1,000 possibilities for a buffer overflow condition!
After being impressed by the exercise, I realized that this could not be accomplished without proper configuration management (CM). I asked Mike about his CM policies. He turned his chair to the nearby bookcase and handed me a binder. The front of the binder was three pages that described the full CM policies. It was replete with rules on management of software, system configurations, and responsibilities of all administrators and developers. The other nearly 300 pages described the CM procedures in graphic detail.
Your organization may not need that many pages to describe your CM process, but having one always is proven to be beneficial.