PCI DSS 3.2
The new version was released on 28th April 2016. There is a six-month overlap between version 3.1 and 3.2 when either can be used. Unless you already have a version 3.1 assessment in progress, it’s best to switch to version 3.2 straight away. Standard 3.2 is due to become fully operational in October of this year.
By Paul Rummery, Securenet Consulting
New extended grace period to remove old SSL / TLS from
systems (after serious vulnerabilities uncovered in the last couple of years
such as HeartBleed and POODLE),
from June 2016 to June 2018.
Refer to https://www.pcisecuritystandards.org
It is still strongly advised to make the changes as soon as
possible, as they represent best practice in cybersecurity.
You will still need to make sure your Risk Mitigation and
Migration Plan (RMMP) is written and up-to-date.
Documenting of cryptographic architecture (3.5.1)
This is a completely new requirement, added to 3.5 which concerns the protection of cryptographic keys. 3.5.1 is required only of service providers and asks them to maintain documentation of the cryptographic architecture they have in place. This includes details of the algorithms, protocols and keys used, description of each keys usage and when it expires and creating an inventory of HSMs and SCDs used for managing the keys.
This new requirement comes into effect at the end of January 2018, after which it will be mandatory.
Patching requirements for vulnerability management (6.2)
Requirement 6 is usually the one of most interest to cybersecurity staff as it concerns vulnerability management. An update has been made to point 6.2, which requires critical security patches to be applied within one month of release. The update applies to any payment applications, both PCI approved or otherwise.
Removal of test data in production (6.4.4)
This requirement was already in place but has been updated to clarify that prior to entering production phase, all test data and accounts must be completely removed from the system. The guidance notes explain that this is to prevent anyone accessing the data from being able to gain intelligence about how the application works.
Change Control Processes (6.4.6)
Requires entities to reassess and document the changes, check their configurations and update documentation such as network diagrams.
New additions such as new hardware and applications be subject to regular security testing such as monthly vulnerability scanning.
The requirement to perform these becomes mandatory in January 2018.
Multi-Factor Identification Requirements (8.3)
Multi-factor authentication. Instead of talking about two-factor authentication, it is now referring to multi-factor authentication. administrators to always use multi-factor authentication – even within the CDE. This means wherever an administrator authenticates to a device, system or application, or gains access to the CDE, they need to authenticate with at least two of the things they know, are or have. With this new requirement only coming into force in July 2018 there is some time to prepare but this could be a big change to implement and in some cases will need new technology solutions to be deployed so it is advisable to start planning straight away.
Service Providers to report failures of critical security control systems (10.8)
This new addition concerns service providers alone, requiring them to report critical security control failures as soon as they occur, to allow action to be taken as soon as possible before an attacker has an opportunity to steal data. The security control measures described include firewalls, IPs, antivirus software, access controls, audit logging mechanisms and segmentation controls.
Service providers to perform penetration testing on segmentation controls (11.3.4.1)
Service providers that use segmentation – will now need to undergo penetration tests every six months, which is twice as often as previously.
Contact us today to discuss your requirements in more detail.
+44(0)7714 209927
+44(0)1273 329753
|
 |