Arquivo mensal: julho 2012

If your organization accepts credit cards online you are likely
more than familiar with the Payment Card Industry Data Security Standard
(PCI-DSS). Since late 2004 this framework for developing payment card data
security processes — including prevention, detection and incident response –
has continued to evolve. The areas covered by PCI-DSS are extensive and range
from installing and maintaining a firewall configuration, monitoring access to
network resources, and even includes testing Web applications, all in order to protect
cardholder data.
A key component of the requirements is quarterly vulnerability
scanning; both to detect and report potential threats. Since January 1st,
2012 all assessments have been required to measure against version 2.0 of the
PCI-DSS standard, which placed increased emphasis on promoting awareness around
new vulnerabilities and exploits quickly. Starting on June 30th, 2012
requirements 6.2 and 6.5.6, formerly best practices, become mandatory for
compliance.
Requirement 6.2 mandates than an organization “establish a
process to identify and assign a risk ranking to newly discovered security
vulnerabilities” affecting the Cardholder Data Environment (CDE). The
assessment procedures go on to say that risk rankings should be based
on industry best practices. For organizations developing the risk ranking
and classification system, best practices equates to an approach that assists
in prioritization for remediation; such as a three-tier model (High-Medium-Low)
or a decimal scale (5.0 down to 1.0). For example, criteria for ranking ‘high’
risk vulnerabilities may include a Common Vulnerability Scoring System (CVSS)
base score of 4.0 or above, and/or a vendor-supplied patch classified
by the vendor as ‘critical,’ and/or a vulnerability affecting a
critical system component. Implementing this risk ranking system within
your organization’s vulnerability management process is important; scanning is
not a vulnerability management program by itself.
For internally developed applications within the scope of an
organization’s CDE, requirement 6.5.6 mandates testing against vulnerabilities
classified as ‘high’ risk as part of the secure application development
process. Applications are still required to be developed based on secure coding
guidelines as defined in Requirement 6.5. This includes the common coding
vulnerabilities outlined within the sub-requirements of 6.5 as well as industry
best practices such as the OWASP Top 10. After June 30th, organizations will
also need to ensure that secure coding guidelines attend to “All ‘High’
vulnerabilities identified in the vulnerability identification process (as
defined in PCI DSS Requirement 6.2).”
For scanning vendors, PCI is requiring a more proactive and
preventive stance towards vulnerabilities. Historically, PCI-certified scanning
vendors have not been required to automatically warn a customer that they are
vulnerable (upon discovering a vulnerability); when section 6.2 becomes a
mandatory requirement, these same vendors will also have to update their
software to ensure that issues are detected in subsequent scans. The ranking
component is partially dependent on individual vendors and how they measure
different results, but this is means that rather than waiting for another
organization to designate the severity level of a specific vulnerability,
vendors will now be required to assign them at least an interim risk ranking on
discovery.
As you might expect given the complexity and associated confusion
around PCI compliance, there are additional requirements both directly and
indirectly affected by 6.2 and 6.5.6 becoming mandatory. Some of these include
verifying that minimum security baselines (MSBs) required by Requirement 2.2
are updated, continued scanning until all vulnerabilities classified as ‘High’
and scored greater than a 4.0 by the CVSS as defined in PCI DSS Requirement 6.2
are resolved. Additionally, when a qualified security assessor (QSA) is engaged,
they will be looking for additional materials related to requirements 6.2 and
6.5.6, including vulnerability management policy, risk ranking or risk
classification methodology.
What does this change mean for those involved? If you are already
following the best practices, perhaps very little from a compliance perspective,
for online retailers the enforcement of this change should make it more
difficult for exploits to remain undetected, hopefully avoiding a greater
number of XSS, SQL-injection and other attacks. For scanning vendors, the
effect of this change results in more efficient detection and notification to
the client. Overall, ensuring that these requirements are addressed prior to
the June 30th deadline will not only reduce the risk of falling out of
compliance with PCI-DSS v2.0 but provide one more step toward making cardholder
data more secure.