martes, 26 de noviembre de 2013

PCI DSS v3.0

This
November has been realised the third version of PCI DSS. The
amendments include a few changes from the previous version in both
the introductory paragraphs and in requirements and test procedures.

Most of the changes are aimed to clarify issues in the
previous version were open to misinterpretation or had raised
important questions for organizations or even QSAs.

However,
we also find some more fundamental changes, such as new requirements,
modified to make requirements more stringent, or also (in less cases)
modified to provide greater flexibility in compliance.

We will
analyse all these major changes including the new version:

We
found a new section called "Implementing PCI DSS into
Business-as-Usual" in which a series of best practices and
recommendations on how it should be implemented so that PCI DSS is
integrated into the processes of organizations are presented. Note
that this is just a series of good practice and therefore are not
binding or supersede any of the requirements of PCI DSS.

Modified
the table in which the requirements, so that now a column in which
the motivation of each requirement. I think it is a very positive
change, and that this explanation will often understand more fully
exactly is being requested in each standard requirement without going
to see any additional document.

Requirement
2.4 which states that the organization must maintain an inventory of
the components included in the scope of PCI DSS to assist in the use
of configuration standards.

As
is known, the PCI DSS Requirement 5 requires the use of anti-virus on
all systems except reach those who are deemed unaffected by malware
(Mainframe, AS400, UNIX, etc.). The new version 5.1.2 requirement
stablish the need to follow the evolution of risks due to malware on
systems that are not normally affected by malware and remove them
from this category if it is necessary.

Another new
requirement included in the sub-requirement 5.3 has been requesting
anti-virus solutions remain activated and can not be disabled or
altered by users.

6.5.10
requirement is considered good practice not mandatory until June 1,
2015. This requirement states that the procedures and policies should
include measures to prevent attacks against authentication frameworks
and web management sessions, including the following:

Bookmark
session tokens (eg cookies) with the flag "secure".

Do
not expose the session ID in the URL.

Incorporate appropriate
timeouts and rotation for the session ID after successful login.

Changed the
requirement 8.2.3 so now that this requirement sets minimum in
complexity and size of the password but allows greater flexibility in
compliance. Although still requires you to use a password of 7 or
more characters and include both numeric and alphabetic characters,
is given the possibility to use other sizes or complexities whatever
remains the same or greater strength in the password to use.

New requirement
(8.5.1) apply only to service providers and requiring these to use
different credentials for remote access to systems of each of its
customers. This requirement will be considered a good practice not
mandatory until July 1, 2015.

The new
requirement 8.6 mandates that, when using authentication mechanisms
other than username / password, these mechanisms are univocally
linked to individual user accounts and ensure that only the
appropriate users can make use of these mechanisms.

Requirement 9.3
is also new in this release and appearance establishes the need to
control physical access to sensitive areas by onsite personal. Also,
it must have procedures for authorizing access and revoke such access
immediately in termination.

Other new
requirements in this release are ranging from 9.9 to 9.9.3. These
requirements require to protect devices that capture the card data
directly through physical interaction with them (card readers, etc.
..). Specifically, the requirements asking for a list of existing
devices, which were visually inspected periodically to detect
anomalies in the same and that is to train staff to detect if devices
have been replaced or tampered keeps.

Requirement
10.5.2 reinforces the generation and review of logs by recording
changes in identification and authentication mechanisms, including
the creation of new accounts or privilege scalation, such as use the
"su" command.

The 10.2.6 has
also been amended to require that the events corresponding to the
stop or pause the audit logs are included, in addition to resetting
or deleting the logs that already required in the previous version.

Requirement
11.1.1 now requests that the inventory of authorized wireless access
points and their corresponding business justification is documented.
Meanwhile, the newly created requirement 11.1.2 establishes the need
for incident response procedures detailing the course of action to
follow in case of detecting unauthorized wireless networks in the
quarterly reviews.

Requirement 11.3
is one of the most significant changes in this new version.
Considered just a good practice until next July 1, 2015 date on which
shall be considered mandatory. The requirement mandates that
organizations have an annual pentest methodology. This methodology
must to consider, almost, the next topics:

Based on
industry-accepted penetration testing approaches.

Includes coverage
for the entire Cardholder data Enviroment perimeter and critical
systems.

Includes testing
from both inside and outside the network.

Includes testing to
validate any segmentation and scope-reduction controls.

Defines
application-layer penetration tests to include, at a minimum, the
vulnerabilities listed in Requirement 6.5 of PCI DSS.

Defines
network-layer penetration tests to include components that support
network functions as well as operating systems.

Includes review and
consideration of threats and vulnerabilities experienced in the last
12 months

Requirement 11.5
has also been modified to provide greater flexibility in compliance.
Now, instead of requiring you install a FIM, it is requested that any
mechanism that allows change detection to alert personnel of
unauthorized critical system files, configuration files or content
files modifications.

Changed the
requirement 12.2 (old 12.1.2) so that now not only the execution of
an annual risk analysis is required, but also after any significant
change in the environment (eg, acquisitions, mergers, relocations,
etc. ..).

New 12.8.5
requires to maintain information about which PCI DSS requirements are
managed by each service provider, and which are managed by the
entity.

And finally, the
new requirement 12.9 apply only to service providers and will be
considered a best practice until July 1, 2015. This requirement will
force service providers to provide their customers and sign specific
clauses which explicitly recognize their responsibility in managing
the security of cardholder data from their customers.

In
conclusion, I think all the changes included in the new version of
the standard are positive and that we have a clear standard, with
less indefined areas and that permits those organizations that implements
PCI DSS not just be compliant but also highly increment the security
of card-holder data that is stored, transmitted or processed by the
organization.