- 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 #3: Use the Security Features of the System
After their successes with fixing buffer overflows and solving a lot of problems by checking the results of system calls and functions, Mike's company started to consider the features they wanted to add to the next release. They were brought back to reality when two very significant customers called and asked why they did not fix two other longstanding access control problems.
After receiving this report from customer service, Mike followed up with personal visits to the customers, where he discovered that the software tried to do its own access controls and ignored security features offered by the operating system. Even though the documentation had explained how to secure that data, the operators were expecting it to follow the same rules as configured in the operating system.
A review of the security features of their software showed that custom controls duplicated controls offered by the supported operating system. In some cases, the review showed that the custom controls did not work as well as those offered by the operating system.
When he heard this, Mike went to his three pages of policy to see whether they were required to use the security features of the operating system over custom controls. To his surprise, this was not a policy. Since he had control over this policy, he added it and had his managers start another review. This time, the review was focused to areas where the security features of the software tried to do the same functions as the operating system. With a select group of six programmers, the three-month review removed a number of security features of the program and placed the reliance on the underlying operating system. Aside from reducing the amount of code that had to be supported, administration of the software became easier when controls were set for the entire system and not for every function. This simplicity also removed a lot of documentation for security features that were no longer required.
Of all the changes made during these reviews, these security changes had the biggest impact. Customers reported that administrators found it easier to set the operating system controls to ensure access. One customer also found that the new paradigm allowed them to track who had seen some documents through the auditing features of the operating system. Mike's company was surprised because this was never requested as a feature by any of their customers. Now, more than half do this type of tracking.