Payment Card Industry Changes Reviewed, by James DeLuccia IV

Hooray we have fresh guidelines on securing the payment card industry infrastructure!  Those that serve customers with credit cards and those security professionals auditing / supporting these service providers have much stronger guidance in what should be done.

The maturing of the standard from its roots has come to the quality and defensibility of any internationally recognized standard.  Consider the progression of the now ISO 27001.  This standard originated in the UK as BS7799, was then adopted by ISO as 17799 and through several iterations of the years became a pillar of reference for organizations around the world.  In fact, the greatest certifications come from Asia-Pacific and Australia.  These regions are the strongest adopters mainly because the governments embraced the BS & ISO framework as the approach.  To the point, PCI’s movement towards language and substance that is less generic (MUST -> SHOULD) and clearer sections with a defined process for compensating controls thrusts PCI on par with ISO 27001 (a standard that has been in development for nearly twice as long).

Since anyone can easily go to the PCI Council change document  I will focus this article on what this means to you Mr/s. Retailer / Bank and you too Mr/s. Assessor.

1.2 – Requirement to limit unnecessary traffic:
–  New language clearly states that only required traffic (documented) be permitted to traverse the network environment.
Retailers:
–  Initially monitor traffic & check with vendors on what protocols (ports) are required for an application to operate properly
–  Once you have a established list of required ports (and directions which these travel) setup your access-control devices to allow these ports w/o logs & log every-time another port is used.  According to our initial work there should not be ANY events
–  After a suitable test period (32 days) on monitor, set the access control devices to block.  This simple process provides the necessary restrictions required under Requirement 1.2 and 1.3 and 1.3, while introducing the restrictions in a non-impact manner on the environment.
Assessors:
–  Two easy ways of testing for this requirement:
–  Pull the configurations and run through a “what-if” tool like SkyBox or some open source virtual environments (the HoneyNet project can be modified for setting up these environments and importing the configurations).
–  Launch a tool like nmap at each network segment being restricted and try to access each device for every single port (tcp & udp)
–  Both approaches provide absolute proof that restrictions are in place and supporting the environment.  What other methods are assessors out there using?  Please comment below…

2.2 – Requirement to be in-line with recognized standards bodies:
–  The intent of this not re-invent the wheel and to leverage organizations that are dedicated to developing and maintaining relevant standards.
–  The best application of this standard is at the point where devices (POS, desktops, servers) are purchased and received.  Organizations should leverage their corporate images towards these standards to ensure broad adoption of the available configurations.  In addition to those posted, the NSA has very strong Microsoft and Unix policy templates that can be easily applied to either system base.  This will greatly reduce the work of following a check sheet and allow for greater tweaking to occur by the administrators.
–  Best bet is to begin applying these configuration standards to the entire organization.  A client of mine was able to reduce the help desk calls by 90% simply by mandating usage of single image (per user class).  If anyone had any problems the systems were “ghosted”, and magically the errors went away….

2.4 – Hosting Providers
–  This requirement is very important for ensuring that not only payment card data is secure, but that the entire digital environment is adequately protected.
–  Simple put – hosting providers must meet security good practices
–  Today most major hosting providers have a SAS 70 Type II done to validate their internal controls and this (depending on the depth of testing) may be sufficient to represent this requirement.  Be aware – that SAS 70s do not traditionally adequately represent a secure environment.  When receiving a SAS 70 report be sure to receive the entire report – and not just the cover letter.  SAS only represents the tests that a companies management wishes to have tested, and these may or may not meet the A.1.1 – A.1.4 requirements.  Be sure that what was tested is within our scope of concern and it was validated without exceptions.

3.4 – Strong Cryptography

–  The intent is to encrypt using algorithms that are sufficient today (as in the day which the technology is in use and being audited).  To that end, references to strong cryptography should adhere to the NIST (or other cryptographic organization) guidelines for the current appropriate security schema.  This is an important change as there was prior confusion on the use of DES, 3DES vs. AES.
–  Bottom line:  Implement the most appropriate encryption standard for the given medium.  Key lengths should be chosen in consideration of the sensitive nature of the data, the amount of processing necessary – a basic cost-based analysis on what should be used.
–  Rule of Thumb:  Choose the best encryption scheme and key length based on the content being encrypted (some algorithms are LESS secure if there is a large amount of encrypted items vs. others are equally secure no matter the number of items encrypted).

4 – Wireless Encryption
–  The standard allows the use of multiple encryption approaches and encourages the layering of preventive security safeguards
–  WEP is allowed, but it must be supported with the addition of other access and encryption technologies.  This is a bit of a burden on the network to have two encryption technologies in use –> best bet is to stay away from WEP and use WPA or another encryption in its place.  This will avoid any redundancy and help maintain basic network performance.

5.1 – Spyware and Adware
–  This technology is now available as an add-on by most enterprise level anti-virus software providers and is an absolute necessity given the threats this technology poses.
–  Threat:  Spyware and Adware are a major source of keyloggers and trojans on systems online.  A recent study showed that nearly 20% of systems have keyloggers installed as a result of spyware/adware.  This malicious code also runs in memory and constantly contacts servers around the world re-installing and updating itself.  This is a waste of corporate system resources and bandwidth.
–  Most organizations that implement this type of technology have a steep introduction period, as most systems have this malicious code already installed, and must be rebuilt (re-imaged / ghosted) from scratch to fully remove the code.  The best approach is try to remove it once and then rebuild.  It is not uncommon for the removal process to take 3 days per device – an extreme waste of time and money.

6.6 Web Applications
–  OWASP top 10 highlighted as the best reference for completely reviewing web threats.  This includes the entire top 10.  The custom code should be protected in one of two ways – a security professional audits the application and validates the top ten are addressed, or a web application firewall is in place.  This is not required until 2008.
–  Retailers will want to ensure that they introduce a SDLC program to improve their code base in active development, and begin requiring a validation of all code purchased through 3rd parties.  This validation can be used upon an audit and reduce cost and audit fees.
–  Assessors should review any third party reports to verify that all ten points have been reviewed and corrected.  In addition, the version validated should be that which is deployed at the time of the audit – time stamps on files of all major component files should be captured for support.

The new standard, as mentioned above, is a great stride in firming the process.  The above review is only a small slice of what the entire standard includes (50 pages in total!).  I strongly encourage everyone to read the standard in its entirety to fully understand the work that has been put in.

As always – Please post any challenges, suggestions, differing opinions on any of what I posted or sections I failed to notice.  I certainly have stepped on many sacred areas in security that normally require a “it depends” (wireless security, auditing sample sizes, web application testing), but that wouldn’t be of any value…

Best regards,

James DeLuccia IV

Full Disclosure:  I am not affiliated with any vendor and have no desire in this post but to give back to a community that has given me so much…  Cheers to Transparency.

Advertisements

One response to “Payment Card Industry Changes Reviewed, by James DeLuccia IV

  1. Pingback: PCI DSS 1.1: What and When? « PCI and Data Security Compliance

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s