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:
1.
Governance
2.
Software
Development
3.
Testing
4.
Deployment
The security practices are implemented
as follows for these 4 business functions:
I.
Governance
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
IV.
Deployment
i. Vulnerability Management
ii. Environment Hardening
iii. Operational Enablement
Governance
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
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.
Pen
Testing
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:
1.
Analysis
2.
Design
3.
Implementation
4.
Testing
5.
Deployment
Analysis
Phase
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
Design
Phase
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.
Implementation
Phase
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.
Testing
Phase
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.
Deployment
Phase
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
b.
Physical
c.
Network
i. Internal devices
ii. Perimeter devices
d.
Host
i. Services
ii. Applications
e.
Application
II.
Education
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
V.
Logistics
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
2.
Reconnaissance
3.
Enumeration
4.
Vulnerability
Scanning
5.
Exploitation
6.
Documentation
VII.
Remediation
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.
