Application testing consists of several different types of testing, which ranges from unit testing and Build Verification Testing (BVT) to functional and integration testing. These types of testing are often conducted with a goal of finding functional or stability bugs in the application code. Chapter 10 explores different forms of code analysis and testing methods in greater depth. Security testing is not specifically covered in Chapter 10, but it is critically important to the overall testing process. Security testing should be driven by the details of the threat model, which is completed before coding. Because threat models describe the likely attacks on the application as well as the mitigation strategies, a security-focused test plan can be easily scoped to the identified attack surface. Clearly, the value of security testing should not be underestimated. A well-defined and focused security-testing strategy helps to close the loop on much of the security-focused design and implementation work recommended in this chapter. Application development teams should ensure that their respective test strategies include a specific focus on security.

In addition to investing in a repeatable security-testing process within your organization, it is also quite valuable to conduct periodic penetration tests against your application. Penetration testing is a method of evaluating your application, infrastructure, or both to determine weaknesses or vulnerabilities. This is often performed by third-party vendors who conduct testing from the perspective of the malicious user. The scope of testing can be targeted toward a specific application or broadened to include social engineering to attempt to gain access to software applications or protected resources. As you might imagine, the intent of penetration testing is to determine the feasibility of an attack and the business impact that could result from a successful exploit. Results of a penetration test are usually presented in the form of a security risk analysis, a set of discovered vulnerabilities, and recommendations for mitigation strategies. It is recommended that organizations invest in penetration testing periodically to not only ensure the security of their application or infrastructure but to get a third-party perspective as well.

Within the Microsoft SDL, the final step in the process is the Final Security Review, or FSR. This process is initiated a few weeks before the final release date of the product, at which time the end-to-end security plan, threat models, risk mitigation strategies, and bug reports are reviewed. The goal of this process is to ensure that the security team within the company has a chance to conduct a final evaluation of the application security prior to release. The results of this process can range from pure acceptance and approval to release, to FSR escalation, which has the potential to delay release. Escalations are often the result of the team failing to meet some portion of the SDL criteria. This process is very beneficial to both the product team and the company as a whole. It ensures that a standard quality bar for security is set and enforced across the products, which ultimately benefits the users from a security perspective and the company from the perspective of reputation and risk management. For additional detail on implementing an FSR process within your company, I recommend reviewing the documentation at http://msdn.microsoft.com/en-us/library/cc307409.aspx.

We spent a great deal of time in this chapter discussing process and software-based security best practices. It is also important to this subject to mention best practices for protecting your application infrastructure with hardware devices. The most common examples of hardware-based infrastructure components that are designed to improve security include firewalls, Intrusion Detection Systems (IDS), and denial of service appliances. These components are often used as a first line of defense against certain forms of attacks. For instance, firewalls are network appliances that are installed between user computers and protected resources on a network. They are used to inspect network traffic that is passing through and either permit or deny access to the resource based on the predefined rules. In contrast, an IDS works in conjunction with a firewall to interrogate network traffic and attempts to detect certain malicious behaviors that are attempting to exploit the resources that it protects. Unlike firewalls, an IDS can detect specific types of attacks such as brute force data-driven application attacks or elevation of privilege attacks. When combined, a firewall and an IDS can offer a solid layer of protection for your application infrastructure. If your applications are Internet facing, you may also find it necessary to add a denial of service appliance. Like firewalls and the IDS, these appliances also monitor network traffic and attempt to detect anomalies in the traffic such as quick ramp-ups or traffic spikes, which could indicate an impending denial of service attack. If these devices detect such anomalies, they can rapidly begin blocking specific IP addresses or perhaps even IP address ranges.