Cisco’s Infographic is an interesting turn on the ROI message as it looks at security from the loss prevention angle rather than earnings.
Especially with Data Centre downtime costing on average $336,000 per hour.
The PCI SSC considered many things when drafting Version 3.0 of the PCI DSS and PA DSS standards including:
- What will improve payment security?
- Global applicability and local market concerns
- Appropriate sunset dates for other standards or requirements
- Cost/benefit of changes to infrastructure
- Cumulative impact of any changes
The nature of the changes reflects the growing maturity of the payment security industry since the Council’s formation in 2006, and the strength of the PCI Standards as a framework for protecting cardholder data. Cardholder data continues to be a target for criminals.
Lack of education and awareness around payment security and poor implementation and maintenance of the PCI Standards leads to many of the security breaches happening today.
The updates address these challenges by building in additional guidance and clarification on the intent of the requirements and ways to meet them. Additionally, the changes in PCI DSS and PA-DSS 3.0 focus…
View original post 1,770 more words
The PCI SSC considered many things when drafting Version 3.0 of the PCI DSS and PA DSS standards including:
- What will improve payment security?
- Global applicability and local market concerns
- Appropriate sunset dates for other standards or requirements
- Cost/benefit of changes to infrastructure
- Cumulative impact of any changes
The nature of the changes reflects the growing maturity of the payment security industry since the Council’s formation in 2006, and the strength of the PCI Standards as a framework for protecting cardholder data. Cardholder data continues to be a target for criminals.
Lack of education and awareness around payment security and poor implementation and maintenance of the PCI Standards leads to many of the security breaches happening today.
The updates address these challenges by building in additional guidance and clarification on the intent of the requirements and ways to meet them. Additionally, the changes in PCI DSS and PA-DSS 3.0 focus on some of the most frequently seen threats and risks that precipitate incidents of cardholder-data compromise. The updated standards will help organizations not by making the requirements more prescriptive, but by adding more flexibility and guidance for integrating card security into their business-as-usual activities. At the same time, the changes will provide increased stringency for validating that these controls have been implemented properly, with more rigorous and specific testing procedures that clarify the level of validation the assessor is expected to perform. Overall, the changes are designed to give organizations a strong but flexible security architecture with principles that can be applied to their unique technology, payment, and business environments.
Version 3.0 updates of PCI DSS and PA-DSS will:
- Provide stronger focus on some of the greater risk areas in the threat environment
- Provide increased clarity on PCI DSS & PA-DSS requirements
- Build greater understanding on the intent of the requirements and how to apply them
- Improve flexibility for all entities implementing, assessing, and building to the Standards
- Drive more consistency among assessors
- Help manage evolving risks / threats
- Align with changes in industry best practices
- Clarify scoping and reporting
- Eliminate redundant sub-requirements and consolidate documentation
Change Drivers
The PCI Standards are updated based on feedback from the industry, per the standards development lifecycle as well as in response to current market needs. Common challenge areas and drivers for change include:
- Lack of education and awareness
- Weak passwords, authentication
- Third-party security challenges
- Slow self-detection, malware
- Inconsistency in assessments
Key Themes
Changes planned for Version 3.0 are designed to help organizations take a proactive approach to protect cardholder data that focuses on security, not compliance, and makes PCI DSS a business-as-usual practice. Key themes emphasized throughout Version 3.0 include:
Education and awareness
Lack of education and awareness around payment security, coupled with poor implementation and maintenance of the PCI Standards, gives rise to many of the security breaches happening today. Updates to the standards are geared towards helping organizations better understand the intent of requirements and how to properly implement and maintain controls across their business. Changes to PCI DSS and PA-DSS will help drive education and build awareness internally and with business partners and customers.
Increased flexibility
Changes in PCI DSS and PA-DSS 3.0 focus on some of the most frequently seen risks that lead to incidents of cardholder data compromise, such as weak passwords and authentication methods, malware, and poor self-detection, providing added flexibility on ways to meet the requirements. This will enable organizations to take a more customized approach to addressing and mitigating common risks and problem areas. At the same time, more rigorous testing procedures for validating proper implementation of requirements will help organizations drive and maintain controls across their business.
Security as a shared responsibility
Securing cardholder data is a shared responsibility. Today’s payment environment has become ever more complex, creating multiple points of access to cardholder data. Changes introduced with PCI DSS and PA-DSS focus on helping organizations understand their entities’ PCI DSS responsibilities when working with different business partners to ensure cardholder data security.
Emerging Technologies
PCI Standards provide a strong framework for protecting payment card data, regardless of the technology or platform used to accept or process it. The PCI DSS and PA-DSS are constructed in a way that their principles can be applied to various environments where cardholder data is processed, stored, or transmitted—such as e-commerce, mobile acceptance, or cloud computing. Specific guidance on the use of emerging technologies and how PCI Standards apply are currently addressed via information supplements produced by PCI Special Interest Groups, and separate guidance documents, such as Mobile Payment Acceptance Security Guidelines for Merchants. As the mobile environment develops, the Council will continue to work with industry stakeholders on developing relevant guidance and/or requirements as appropriate. Technologies such as point-to-point encryption and tokenization are being addressed as separate initiatives. For more information, please visit the PCI SSC website.
Change Highlights. Types of changes to the Standards are categorized as follows:
- Clarification – Clarifies intent of requirement. Ensures that concise wording in the standard portrays the desired intent of requirements.
- Additional Guidance – Explanation, definition, and/or instruction to increase understanding or provide further information or guidance on a particular topic.
- Evolving Requirement – Changes to ensure that the Standards are up to date with emerging threats and changes in the market.
Specific PCI Data Security Standard (PCI DSS) 3.0 changes
|
Requirement |
PCI DSS Update |
Purpose / Need Addressed |
|
1 |
Have a current diagram that shows cardholder data flows. |
To clarify that documented cardholder data flows are an important component of network diagrams. |
|
2 |
Maintain an inventory of system components in scope for PCI DSS. |
To support effective scoping practices. |
|
5 |
Evaluate evolving malware threats for systems not commonly affected by malware. |
To promote ongoing awareness and due diligence to protect systems from malware. |
|
6 |
Update list of common vulnerabilities in alignment with OWASP, NIST, SANS, etc., for inclusion in secure coding practices. |
To keep current with emerging threats. |
|
8 |
Security considerations for authentication mechanisms such as physical security tokens, smart cards, and certificates. |
To address feedback that requirements for securing authentication methods other than passwords need to be included. |
|
9 |
Protect POS terminals and devices from tampering or substitution. |
|
|
11 |
Implement a methodology for penetration testing, and perform penetration tests to verify that the segmentation methods are operational and effective. |
To address requests for more details for penetration tests, and for more stringent scoping verification. |
|
12 |
Maintain information about which PCI DSS requirements are managed by service providers and which are managed by the entity. Service providers to acknowledge responsibility for maintaining applicable PCI DSS requirements. |
To address feedback from the Third Party Security Assurance SIG. |
|
General |
Clarified that sensitive authentication data must not be stored after authorization even if PAN is not present. |
To ensure better understanding of protection of sensitive authentication data. |
|
General |
Added guidance for implementing security into business-as-usual (BAU) activities and best practices for maintaining on-going PCI DSS compliance. |
To address compromises where the organization had been PCI DSS compliant but did not maintain that status. Recommendations focus on helping organizations take a proactive approach to protect cardholder data that focuses on security, not compliance, and makes PCI DSS a business-as-usual practice. |
|
General |
Added guidance for all requirements with content from the former Navigating PCI DSS Guide. |
To assist understanding of security objectives and intent of each requirement. |
|
General |
ROC reporting section relocated to a separate reporting template. |
To simplify and streamline the reporting process. |
|
General |
Enhanced testing procedures to clarify the level of validation expected for each requirement. |
To put more emphasis on the quality and consistency of assessments. |
|
Multiple |
Incorporate security policy/procedure requirements into each requirement (replaces former 12.1.1 and 12.2). |
To address feedback that policy topics should more closely align with the related technical PCI DSS requirement. |
|
2 |
Clarified that changing default passwords is required for application/service accounts as well as user accounts. |
To address gaps in basic password security practices that are leading to compromises. |
|
3 |
Provided flexibility with more options for secure storage of cryptographic keys, and clarified principles of split knowledge and dual control. |
To clarify common misunderstandings about key management. |
|
8 |
Provided increased flexibility in password strength and complexity to allow for variations that are equivalent. Revised password policies to include guidance for users on choosing strong passwords, protecting their credentials, and changing passwords upon suspicion of compromise. |
To address feedback on improving password security. Changes focus on increased flexibility and user guidance rather than new requirements. |
|
10 |
Clarified the intent and scope of daily log reviews. |
To help entities focus log-review efforts on identifying suspicious activity and allow flexibility for review of less-critical logs events, as defined by the entity’s |
PCI Payment Application Data Security Standard (PA-DSS) 3.0 changes
|
Requirement |
PCI DSS Update |
Purpose / Need Addressed |
|
5 |
Enhanced requirements for system development processes including periodic security reviews, verifying integrity of source code, a versioning methodology, use of application threat-modeling techniques, and a formal authorization process before final release. |
To provide greater assurance regarding PA-DSS vendor development practices. This will allow for simplified processes for changes to PCI-listed applications and increased flexibility for vendors. |
|
|
For inclusion in secure coding practices, update list of common vulnerabilities in alignment with OWASP, NIST, SANS, etc. |
To keep current with emerging threats. |
|
7 |
New requirement for application vendor to provide release notes for all updates. |
To help merchants more easily determine whether their application version is on the PA-DSS list. |
|
14 |
New requirement to focus on training of integrators/resellers (formerly in Requirement 13) and vendor personnel. |
To emphasize importance of training for integrator/reseller and vendor personnel. |
|
General |
Clarify that PA-DSS applications are in scope for an organization’s PCI DSS assessment. |
To address common misconception that use of a PA-DSS application guarantees PCI DSS compliance. |
|
General |
Added guidance for all requirements. |
To assist understanding of security objectives and intent of each requirement. |
|
General |
Relocated ROV reporting section to a separate reporting template. |
To simplify and streamline reporting process. |
|
General |
Relocated information on PA-DSS eligibility and roles and responsibilities to the PA-DSS Program Guide. |
To provide more clarity by removing repetitive information. |
|
General |
Updated testing procedures for verifying contents of PA-DSS Implementation Guides. |
To put more emphasis on quality Implementation Guides. |
|
2 |
Removed requirement regarding use of full disk encryption solutions. |
To address confusion on inclusion of this requirement in PA-DSS. |
|
3 |
Enhanced requirements to ensure that changing of default passwords is enforced by the application and appropriately validated. |
To address feedback that unchanged default passwords are a common cause of merchant compromises. |
|
|
Updated requirement to require use of a one-way cryptographic algorithm with an input variable to render passwords unreadable. |
To address feedback that passwords need to be stored and transmitted more securely. |
|
8 |
Relocated two requirements from Requirement 5 and 10 to align them with other requirements that facilitate a secure PCI DSS environment. |
To clarify intent of the requirements for improved understanding. |
|
10 |
Clarified the requirement for two-factor authentication applies to network access originating outside the customer’s network. |
To improve understanding of when two-factor authentication is applicable. |
|
13 |
Refocused requirement solely on the Implementation Guide, and removed requirements for training of integrators/resellers to new Requirement 14. |
To put more emphasis on quality Implementation Guides. |
The PCI Security Standards Council (PCI SSC), have published PCI Data Security Standard (PCI DSS) and Payment Application Data Security Standard (PA-DSS) 3.0 Change Highlights as a preview of the new version of the standards coming in November 2013.
Version 3.0 to focus on flexibility, education and awareness, and security as a shared responsibility
The changes will help companies make PCI DSS part of their business-as-usual activities by introducing more flexibility, and an increased focus on education, awareness and security as a shared responsibility.
The seven-page document is part of the Council’s commitment to provide as much information as possible during the development process and eliminate any perceived surprises for organizations in their PCI security planning. Specifically, the summary will help PCI Participating Organizations and the assessment community as they prepare to review and discuss draft versions of the standards at the 2013 Community Meetings in September and October.
Changes to the standards are made based on feedback from the Council’s global constituents per the PCI DSS and PA-DSS development lifecycle and in response to market needs.
Key drivers for version 3.0 updates include:
- lack of education and awareness
- weak passwords and authentication challenges
- third party security challenges
- slow self-detection in response to malware and other threats
- inconsistency in assessments
Today, most organizations have a good understanding of PCI DSS and its importance in securing card data, but implementation and maintenance remains a struggle – especially in light of increasingly complex business and technology environments,” said Bob Russo, PCI SSC general manager
The challenge for us now is providing the right balance of flexibility, rigor and consistency within the standards to help organizations make payment security business-as-usual. And that’s the focus of the changes we’re making with version 3.0
Based on feedback from the industry, in 2010 the PCI SSC moved from a two-year to a three-year standards development lifecycle. The additional year provides a longer period to gather feedback and more time for organizations to implement changes before a new version is released. Version 3.0 will introduce more changes than version 2.0, with several new sub-requirements.
Proposed updates include:
- Recommendations on making PCI DSS business-as-usual and best practices for maintaining ongoing PCI DSS compliance
- Security policy and operational procedures built into each requirement
- Guidance for all requirements with content from Navigating PCI DSS Guide
- Increased flexibility and education around password strength and complexity
- New requirements for point-of-sale terminal security
- More robust requirements for penetration testing and validating segmentation
- Considerations for cardholder data in memory
- Enhanced testing procedures to clarify the level of validation expected for each requirement
- Expanded software development lifecycle security requirements for PA-DSS application vendors, including threat modeling
These updates are still under review by the PCI community. Final changes will be determined after the PCI Community Meetings and incorporated into the final versions of the PCI DSS and PA-DSS published in November.
PCI DSS and PA-DSS 3.0 will provide organizations the framework for assessing the risk involved with technologies and platforms and the flexibility to apply these principles to their unique payment and business environments, such as e-commerce, mobile acceptance or cloud computing,” added Troy Leach, PCI SSC chief technology officer
The 2013 Live Threat Intelligence Impact Report from the Ponemon Institute, sponsored by Norse reveals how 700+ respondents from 378 enterprises defines
- What “live threat intelligence” is.
- How global enterprises are using it defend against compromises, breaches and exploits;
- The financial damage that slow, outdated and insufficient threat intelligence is inflicting on them.
The key findings were:
- They spent an average of $10 million in the past 12 months to resolve the impact of exploits.
- If they had actionable intelligence about cyberattacks within 60 seconds of a compromise, they could reduce this cost on average by $4 million (40%).
- Those that have been able to stop cyberattacks say they need actionable intelligence 4.6 minutes in advance to stop them from turning into compromises.
- 60% were unable to stop exploits because of outdated or insufficient threat intelligence.
- Those not successful in detecting attacks believe 12 minutes of advanced warning is sufficient to stop them from developing into compromises.
- 57% believe threat intelligence currently available to most companies is often too stale to enable them to grasp and understand the strategies, motivations, tactics and location of attackers.
- Only 10% know with absolute certainty that a material exploit or breach to networks or enterprise systems occurred.
Other findings include:
- 72% believe that in order to defend against an attack, it is important to essential to know the geo-location of attack sources.
- 69% believe that future attacks are most likely to come from China, but 71% said they were seeing most of their current attacks originating in the U.S.
- 57% of say Advanced Persistent Threats (APTs) are their greatest concern; 54% say they are most concerned about root kits; 45% say SQL and code injection is their biggest worry.
- 35% rely on IT security teams’ “gut feel” to determine whether or not an attack will occur.
- 34% believe that criminal syndicates pose the biggest threat to their enterprise; 19% said state-sponsored attackers were the greatest threat.
- 9% cannot determine whether or not they are compromised.
- A wide range of technologies is used to gather threat intelligence, ranging from SIEM to IDS to IAM to Big Data analytics and firewalls. On a one-to-10 scale of effectiveness, only 22% rate these technologies between a 7 and a 10, and 78% rate them between a 1 and 6.
These findings are startling but not surprising. Enterprises are conditioned to believe that after-the-fact threat intelligence is all that is available, a perception that is leaving them open to compromises and data breaches that are costing them millions,” said Sam Glines, CEO, Norse. “This report makes it clear that enterprises are in need of an advanced level of threat intelligence that shrinks the interval between attack identification and mitigation down to minutes or even seconds if they are to survive the modern-day cyberthreat juggernaut
Ponemon Institute has conducted IT security research for over a decade, and this is one of the first studies that reveals the facts behind the impact that weak threat intelligence is having on organizations,” said Larry Ponemon, founder and chairman of Ponemon Institute. “Anyone who reads this report will come to understand that live threat intelligence must be an integral part of any security strategy.”
To view the report click here.
Is Your Business Safe From Cyberattacks? An excellent Infographic from Imperva shows the seven stages of a targeted attack and makes eight recommendations on how to protect your data.
The state of corporate data is an interesting Infographic showing the extent data could leak from a corporate network.
