Creating Vulnerabilities: An Example

Now, let’s walk through a scenario using all of the previously mentioned items to understand how bad things happen to well-intentioned programs. The e-mail program mentioned at the beginning of this section is a great example. Later, we will walk through all the steps of the SDLC and discover what can go wrong.

1. Concept and proposal: XYZ Company decides that the world would be a better place if they could send e-mails to each other using a special program that presents and manages the e-mails better than any other program on the market. It will use a specially adapted format that puts unique functionality inside the messages.What could go wrong? Complexity has been introduced into a system that is relatively simple. Similar to the GDI+ API example, more complexity creates more opportunity for faults. If the new functionality is so critical to the success of a product, the security of the unique parts of the system will have to be stressed from the outset of the project. At a minimum, the reliability and security of the key components should almost be a feature in the concept.
2. Requirements gathering: The detailed requirements for all the functionality are gathered from those who have created the concept. There is tremendous enthusiasm for all the great capabilities that will be included and how they will enhance the business model. This should lead to great things one day. What could go wrong?None of the requirements include security or reliability features. These capabilities should be part of any application requirements. Every idea that comes out of the requirements gathering process creates a certain amount of scope creep that can lead to fundamental design flaws. In addition to minimizing growth in cost and schedule, containing scope during the requirements phase can minimize the opportunity for the creation of vulnerabilities.
3. Design: Details of the application, including databases, file systems, and operating system compatibility, are designed on paper. What could go wrong? The design, like the requirements, considers only functionality. All of the focus is on getting the application working. Some work should be put into having the application create restrictive areas of data flow prior to any processing that can validate inputs and outputs to assure that they stay within the application’s functional parameters. Points of data validation and authorization should be established for interprocess communications. One process should be able to verify that the data coming from another process is valid and that the source process is legitimate and operating with authorization. Some threat modeling should begin at this phase. By identifying the areas that are at high risk for exploitation, the team can focus efforts on making sure the most vulnerable components are especially hardened.
4. Code: After the design is complete, the programs are written. What could go wrong? This is the most famous part of systems development in the vulnerability world. The programmers fail to agree on best practices for coding to avoid problems like buffer overflows or other such vulnerabilities. Secure coding best practices should be used, such as bounds checking in dynamically sized data structures and input validation.
5. Test: Testing goes at a feverish pace. Bugs are found and quickly fixed. Testers keep verifying that all of those requirements that did not include security components are correctly implemented. What could go wrong? Testing of the application has the most time pressure. Managers want to see the product in production and have little tolerance for delay. Testers focus only on functionality and often skip regression tests. This is when developers break things for the sake of getting through this phase. Some kind of penetration testing of the product should be conducted with guidance from the previously mentioned threat model.
6. Deployment: Finally, the product is ready. It is packaged and shipped to unsuspecting customers worldwide. Documentation is included that explains how to install and use the program. What could go wrong? The documentation does not include any information about the most appropriate, secure configuration of the system upon which the software will run. It does not say that certain ports should not be open on the network interface to any IP address except the supporting server. Some plans should be made by the development team to respond to vulnerabilities that are discovered. At this point, a much larger group of penetration testers will begin working on the application.
7. Identification: An interested user of the application wonders what would happen if an e-mail is sent with an unusually designed message that matches the processing requirements for a particular module of the e-mail software. But, the user structures the message to be larger than that module’s standard data structure calls for. The program crashes, leaving the operating system with fragments of the message in memory.
8. Exploitation: The user now wonders whether he could imbed a program in the previously mentioned message to stay in memory and run. It works. A small “hello world” program runs.
9. Compromise: The now-very-excited user develops a more improved version of the message that creates more messages using the program and sends copies of itself to others in the address book, an address book that is made more accessible by the powerful functionality built into the e-mail software. The new product’s first e-mail worm is born!

(Guidance: Remove the vulnerabilities that could be exploited early and often. Long term, this decreases the workload on IT and Security, and lowers the cost of detection and prevention tools to achieve a similar level of security.)