Deployment: Penetration Testing (PT)
The overall goal of the Penetration Testing practice is quality control. Those performing penetration testing must ensure the detection and correction of security defects. The SSG must enforce adherence to standards and the reuse of approved security features.
PT Level 1: Remediate penetration testing results. Managers and the SSG must initiate the penetration testing process, with internal or external resources. Managers and the SSG must ensure that deficiencies discovered are fixed and that everyone is made of aware of progress.
PT1.1
Use external penetration testers to find problems. Many organizations are not willing to address software security until there is unmistakable evidence that the organization is not somehow magically immune to the problem. If security has not been a priority, external penetration testers demonstrate that the organization’s code needs help. Penetration testers could be brought in to break a high-profile application in order to make the point. Over time, the focus of penetration testing moves from “I told you our stuff was broken” to a smoke test and sanity check done before shipping. External penetration testers bring a new set of eyes to the problem.
PT1.2
Feed results to defect management and mitigation system. Penetration testing results are fed back to development through established defect management or mitigation channels and development responds using their defect management and release process. The exercise demonstrates the organization’s ability to improve the state of security. Many firms are beginning to emphasize the critical importance of not just identifying but more importantly fixing security problems. One way to ensure attention is to add a security flag to the bug tracking and defect management system.
PT1.3
Use pen testing tools internally. The organization creates an internal penetration testing capability that makes use of tools. This capability can be part of the SSG, with the SSG occasionally performing a penetration test. The tools improve efficiency and repeatability of the testing process. Tools can include off the shelf products, standard issue network penetration tools that understand the application layer, and hand-written scripts.
PT Level 2: Schedule regular penetration testing by informed, internal penetration testers. The SSG must create an internal penetration testing capability that is periodically applied to all applications. The SSG must share its security knowledge and testing results with all penetration testers.
PT2.2
Provide penetration testers with all available information. Penetration testers, whether internal or external, are equipped with all available information about their target. Penetration testers can do deeper analysis and find more interesting problems when they have source code, design documents, architecture analysis results, and code review results. Give penetration testers everything you have created throughout the SSDL. If your penetration tester doesn’t ask for the code, you need a new penetration tester.
PT2.3
Periodic scheduled pen tests for app coverage. Test applications periodically according to an established schedule (which could be tied to the calendar or to the release cycle). The testing serves as a sanity check and helps ensure yesterday’s software isn’t vulnerable to today’s attacks. High-profile applications might get a penetration test at least once a year. One important aspect of periodic testing is to make sure that the problems identified in a penetration test are actually fixed and they don’t creep back into the build.
PT Level 3: Carry out deep-dive penetration testing. Managers must ensure that the organization’s penetration testing knowledge keeps pace with advances by attackers. The SSG must take advantage of organizational knowledge to customize penetration testing tools.
PT3.1
Use external penetration testers to perform deep dive (one-off bugs/fresh thinking). The organization uses external penetration testers to do deep-dive analysis for critical projects and to introduce fresh thinking into the SSG. These testers are experts and specialists. They keep the organization up to speed with the latest version of the attacker’s perspective and they have a track record for breaking the type of software of interest. Skilled penetration testers will always break a system. The question is whether they demonstrate new kinds of thinking about attacks that can be useful when designing/implementing/hardening new systems. Creating new types of attacks from threat intelligence and abuse cases prevents checklist-driven approaches that look for known types of problems.
PT3.2
Have SSG customize penetration testing (tools and scripts). The SSG either creates penetration testing tools or adapts publicly available tools so they can more efficiently and comprehensively attack the organization’s systems. The tools improve the efficiency of the penetration testing process without sacrificing the depth of problems the SSG can identify in the organization’s systems. Tools that can be tailored are always preferable to generic tools.