Search

Brian Pennington

A blog about Cyber Security & Compliance

Month

August 2013

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.

100,000 new security threats are identified each day

PCI-DSS and PA-DSS Version 3.0 – the full highlights and changes

Brian Pennington

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.

 

PCI DSS Version 3, what does it have in store for you?

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 lack of live cyberthreat intelligence could be costing businesses millions

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.

94% of all data compromised involves servers

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.

Is your business safe from a cyber attack

The state of corporate mobile data

The state of corporate data is an interesting Infographic showing the extent data could leak from a corporate network.

druva-insync-mobile-corporate-data-corrected jpeg

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: