Pen Testing Process, Remediation, and Secure Development Lifecycle
Starting a pen testing process for PCI Compliance can be quite a challenge for many organizations. Often this process is cumbersome because it rarely has buy in from Application, Infrastructure, and Operations Teams. In fact, these teams often feel they are forced into it and are reluctant to comply because it is not their problem. They feel security is the problem of Compliance and not a concern of the product or system itself. They often do not want to foot the bill for implementing security measures and testing the product.
We need to move away from this model, the model that security is not the responsibility of the application owners. This model is not conducive to teamwork and growth in the organization as a whole. It often feels that Compliance is fighting a one army battle against legions of other armies. And while Compliance often wins, it is often overwhelming to work in an environment of such politics. It is hard to get 100% PCI Compliance with this model because it relies on the goodwill of the teams to do what they feel is right. There is often a lot of politics to get them to even cooperate. Obviously, this model leads to much distress and headaches in implementing PCI within an organization because people don’t understand what their roles are. There is always a certain percentage that fail to cooperate and they have to be strong armed.
The model we need to move to is ownership of security and PCI Compliance from within the application teams and network operations. They have to take responsibility for the security in their product and systems. They have to be proactive in maintaining PCI Compliance. This is the model often used in companies that have successfully implemented PCI Compliance with a finely tuned model and everyone knows their role. There is no need to coerce application teams and explain to them why they need a security test done hoping they will cooperate. We need to move into a model of taking responsibility and taking ownership of security and PCI Compliance.
The new model stresses maturity in the pen testing process, remediation, and secure development lifecycle where the responsibility of getting the pen test conducted rests upon the application and system teams and Compliance is there to arbitrate if any issues arise. Compliance is there to enforce and report on PCI Compliance as well but the responsibility does not rest entirely upon them.
This is a proposed top down model.
In this new model, the application teams should understand the Secure Development Lifecycle (SDL). This model starts off with understanding the 4 business areas of secure software development:
2. Software Development
The security practices are implemented as follows for these 4 business functions:
i. Strategy and Metrics
ii. Policy and Compliance
iii. Education and Guidance
II. Software Development
i. Risk Assessment
ii. Security Requirements
iii. Secure Architecture
III. Quality Assurance
i. Secure Design Review
ii. Security Testing
iii. Secure Code Review
i. Vulnerability Management
ii. Environment Hardening
iii. Operational Enablement
Governance consists of the processes and procedures related to how an organization manages overall software development activities. This includes providing education and guidance to application and platform teams on security topics relevant to individual job functions. This is so that everyone understands their job roles and learns to work with Compliance instead of against them. Policy and Compliance involves setting up a security and compliance control and audit framework for the organization to achieve increased assurance in software under construction and in operation. Strategy and Metrics involves the overall strategic direction of the software assurance program and instrumentation of processes and procedures to collect metrics about the company's security posture.
Software Development consists of processes and procedures of how the organization defines goals and creates software within development projects. This includes product management, requirements gathering, high-level architecture specification, detailed design, and implementation. Here a risk assessment is performed on the application by a Security Architect or through Compliance, security requirements are defined, and a secure architecture is defined by the application security architect.
As the responsibility of the application team to get a PCI application pen tested annually, or after a major change, is understood and owned by the application team, it is their responsibility to schedule the penetration testing and make sure the vulnerability findings are remediated. It is their responsibility to meet with PCI Compliance.
Penetration tests are not just limited to applications but also include host, network, physical, and work flow/policy processes.
The findings of the penetration test are uploaded into a Governance Risk Compliance (GRC) system and the remediation process is tracked there. Reports can be executed at any point to determine the PCI Compliance posture of the organization. The status of each vulnerability is tracked by date of finding, status such as fixed or overdue, amount of time elapsed since finding was discovered, and more importantly the product or application owner. This allows management to see at a snapshot how individual departments and teams across the enterprise are in relation to compliance. It also promotes accountability.
Secure Development Lifecycle
Security is not something that is done at the last minute before releasing a product to production. Security is something that has to be built into the product. Security has to be incorporated into the product development lifecycle. Software development can be roughly broken into 5 phases:
At the analysis phase where application requirements are being defined, the security requirements must be taken into account. This is where the corporate security standards and regulatory requirements are taken into account when developing an application and put into the application requirements. A security risk assessment is performed on the application by a Security Architect or through Compliance
At the design phase, the application security architect reviews the application architecture and defines a security architecture. Threat modeling can be done here but is not required for PCI. The application security architect also designs and makes recommendations on needed security design based on the application design and looks for any security oversights by the application team. This is called a secure design review and ensures adequate security mechanisms are in place and adherence to corporate and regulatory security standards are designed into the application.
The implementation or coding phase requires that the application developers code according to the security standard of the organization. They may or may not entail help from the application security architect to assist on how to handle the more difficult implementation parts. Secure code review should be done by software development at this point as code is being developed. Assistance from automated static code analyzers can be used to help the developers.
The testing phase will consist of Quality Assurance (QA) conducting security testing. QA will run the final secure code scan and verify that all important security defects have been resolved by the development team prior to release. Compliance can assist with the secure code review and assigning business priority. Penetration testing can be done on the application prior to release but is not required by PCI unless it is a major application upgrade. All identified issues are to have a remediation plan and schedule. Critical vulnerabilities must be fixed prior to releasing software in production.
The deployment phase consists of the processes and procedures of how an organization manages release of software developed. This includes deploying applications to internal or external hosts, and the normal operations of software in the run-time environment. This includes vulnerability management, environment hardening, and operational enablement. The security architect does a final review of the application and network deployment configuration prior to release making sure that it is deployed in a secure manner and meets with the company’s security standards. Application security monitoring and an incident response plan is needed.
Pen Testing Process
The following process explains how to implement Pen Testing to meet PCI Compliance.
I. Identify Type of Pen Tests To Be Conducted
a. Work Flow/Policy
i. Internal devices
ii. Perimeter devices
a. Educate teams as to their responsibility for maintaining PCI Compliance
III. Identify PCI Scope
a. Identify applications and pen tests to conduct
b. Notify application and system owners of the compliance they must maintain
IV. Identify Rules of Engagement
a. What can and can not be done.
b. Produce pen testing authorization letter
a. Application and system owners schedule required pen tests
b. Sign Off on pen testing authorization letter
c. Coordinating the pen test
d. Give access to the environment for testing including test accounts and support
VI. Actual Pen Test
1. Information Gathering
4. Vulnerability Scanning
a. Distribute pen test report to application and system owners
b. Log all defects from pen test into a bug tracking system
c. Meet with application or system owners to discuss test and timetables for remediation
d. A GRC system and/or project manager needs to track the vulnerabilities over time and push the application or system owners to fix all issues.