{"id":2892,"date":"2013-12-07T13:16:25","date_gmt":"2013-12-07T07:46:25","guid":{"rendered":"https:\/\/www.qadit.com\/blog\/?p=2892"},"modified":"2014-01-02T13:20:13","modified_gmt":"2014-01-02T07:50:13","slug":"pci-dss-version-3-0-released","status":"publish","type":"post","link":"https:\/\/qadit.com\/blog\/pci-dss-version-3-0-released\/","title":{"rendered":"PCI DSS Version 3.0 Released"},"content":{"rendered":"

PCI Security Standards Council (PCI SSC) has recently released Version 3.0 of the PCI Data Security Standard (PCI DSS) and Payment Application Data Security Standard (PA DSS). Organizations have one year (till December 31, 2014) to become compliant with the new standard.
\n 
\n
\nThe new requirements for PCI DSS are:<\/strong>
\n 
\n1.1.3 \tA Current diagram that shows cardholder data flows
\n2.4 \tMaintain an inventory of system components in scope for PCI DSS to support development of configuration standards.
\n5.1.2\tEvaluate evolving malware threats for any systems not considered to be commonly affected by malicious software.<\/p>\n

5.3\tEnsure that anti-virus solutions are actively running (formerly in 5.2), and cannot be disabled or altered by users unless specifically authorized by management on a per-case basis. <\/p>\n

6.5.10\tCoding practices to protect against broken authentication and session management. Effective July 1, 2015
\n8.5.1\tService providers with remote access to customer premises, to use unique authentication credentials for each customer. Effective July 1, 2015
\n8.6\tWhere other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.) that the mechanisms must be linked to an individual account and ensure only the intended user can gain access with that mechanism.
\n9.3\tControl physical access to sensitive areas for onsite personnel, including a process to authorize access, and revoke access immediately upon termination. <\/p>\n

9.9.x\tProtect devices that capture payment card data via direct physical interaction with the card from tampering and substitution. Effective July 1, 2015
\n11.1.2\tAlign with an already existing testing procedure, for incident response procedures if unauthorized wireless access points are detected.
\n11.3\tTo implement a methodology for penetration testing. Effective July 1, 2015. PCI DSS v2.0 requirements for penetration testing must be followed until v3.0 is in place.
\n11.3.3\tCreated from former testing procedure (11.3.b) to correct exploitable vulnerabilities found during penetration testing and repeat testing to verify corrections.<\/p>\n

11.3.4\tIf segmentation is used to isolate the CDE from other networks, to perform penetration tests to verify that the segmentation methods are operational and effective.
\n11.5.1\tTo implement a process to respond to any alerts generated by the change-detection mechanism (supports 11.5) <\/p>\n

12.8.5\tTo maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity. <\/p>\n

12.9\tService providers to provide the written agreement\/acknowledgment to their customers as specified at requirement 12.8. Effective July 1, 2015
\n 
\nThe new requirements for PA DSS are:<\/strong>
\n 
\n3.1.1 \u2013 3.1.2\tNew requirements created from former Testing Procedures 3.1.b \u2013 3.1.c to ensure that changing of default passwords is enforced by the application and appropriately validated.
\n3.4 \t\tApplications to limit access to required functions\/resources and enforce least privilege for built-in application accounts. <\/p>\n

5.1.5\t\tPayment application developers to verify integrity of source code during the development process
\n5.1.6 \t\tPayment applications to be developed according to industry best practices for secure coding techniques
\n5.1.7\t\tNew requirement created from former Testing Procedures 5.2.a and 5.2.b for payment application developers to be trained in secure development
\npractices. <\/p>\n

5.2.10\t\tAddress \u201cBroken authentication and session management.\u201d <\/p>\n

5.4\t\tPayment application vendor to define and implement a versioning methodology in accordance with PA-DSS Program Guide<\/p>\n

5.5\t\tPayment application vendors to incorporate risk assessment techniques into their software development process.
\n5.6\t\tPayment application vendors to implement a formal authorization process prior to final release.
\n6.3\t\tNew Requirement 6.3 created from former Testing Procedure 6.2.b.
\n7.3\t\tThe application vendor to provide release notes for all application updates
\n10.2.2\t\tVendors who provide support\/maintenance services to customers to maintain unique authentication credentials for each customer. <\/p>\n

13.1.1\t\tValidate that the PA-DSS Implementation Guide is specific to the application and version(s) being assessed. <\/p>\n

14\t\tNew requirement to focus on instructional documentation and training programs, including internal training for vendor personnel with
\nPA-DSS responsibilities.<\/p>\n

14.1\t\tProviding information security and PA-DSS training for vendor personnel with PA-DSS responsibility at least annually. <\/p>\n

14.2\t\tAssignment of PA-DSS responsibilities to vendor personnel.
\n 
\nOther than the new requirements mentioned above, there are many clarifications and enhanced requirements for certain points which are available on the council’s website. <\/p>\n","protected":false},"excerpt":{"rendered":"

PCI Security Standards Council (PCI SSC) has recently released Version 3.0 of the PCI Data Security Standard (PCI DSS) and Payment Application Data Security Standard (PA DSS). Organizations have one year (till December 31, 2014) to become compliant with the new standard.  <\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[24],"tags":[291,67],"class_list":["post-2892","post","type-post","status-publish","format-standard","hentry","category-grc","tag-pa-dss","tag-pci-dss"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p9AH7Q-KE","_links":{"self":[{"href":"https:\/\/qadit.com\/blog\/wp-json\/wp\/v2\/posts\/2892","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/qadit.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/qadit.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/qadit.com\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/qadit.com\/blog\/wp-json\/wp\/v2\/comments?post=2892"}],"version-history":[{"count":0,"href":"https:\/\/qadit.com\/blog\/wp-json\/wp\/v2\/posts\/2892\/revisions"}],"wp:attachment":[{"href":"https:\/\/qadit.com\/blog\/wp-json\/wp\/v2\/media?parent=2892"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/qadit.com\/blog\/wp-json\/wp\/v2\/categories?post=2892"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/qadit.com\/blog\/wp-json\/wp\/v2\/tags?post=2892"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}