Requirement 6: Develop and maintain secure systems and software

This requirement covers the security of applications and change management. It governs how systems and applications are developed and maintained, whether by the organizations or third parties.

Full compliance: There was a very substantial 10.1 pp increase on Requirement 6, from a low 60.4% to 70.5%. Organizations applied more focus on patching and software vulnerability management. The improvement in full compliance may also be influenced by the increase in compensating controls.

Control gap: The control gap narrowed considerably from 6.7% to a relatively low 3.2%. This is due in part to improvements in Control 6.2, where compliance against 6.2.b improved by 11.4 pp, and Control 6.2 improved by 9.0 pp.

Compensating controls: The use of compensating controls increased from 11.0% to 15.0%. Requirement 6 is, for a second year in a row, the requirement that is most compensated, followed by Requirement 8. Control 6.2 was compensated by an average of 14.5% of organizations (+4.1 pp); there was a small increase in the compensating of Control 6.4.

Requirement 6: Develop and maintain secure systems and software

Addressing the cause to avoid treating the symptoms

How clarity on goals, requirements and constraints strengthens the control environment

With proper planning, design and execution, PCI security compliance programs succeed quietly, protecting payment card data day after day. Then there are the programs that fail spectacularly, sometimes resulting in a publicly disclosed compromise. The success of the PCI DSS over its nearly 20-year history is punctuated by several high-profile payment card data breaches, and those massive program failures make sensational stories. Not surprisingly, all findings and data made available from various PCI Forensic Investigator (PFI) investigations confirm that none of the organizations that experienced confirmed payment card data breaches were compliant with the PCI DSS requirements at the time of the breach. Furthermore, no known, disclosed and documented cases exist of any payment card data breach where evidence supported that the breached entity had all required PCI DSS controls in place at the time of the breach. In all known cases, numerous key security requirements were not in place— usually with several being material to the breach. This is well documented in several of our previous PSR editions.

That there are negative consequences of a data compromise is a cold, hard reality. In the aftermath, a company’s CISO, its security team and others find themselves in the hot seat, responding to tough questions from senior management and third-party forensic investigators—about the what, when, where, how and why of the data compromise.

Publications like the Verizon Data Breach Investigations Report (DBIR) provide the opportunity to learn from others’ mistakes. It’s critical to document who is targeted by which threat actors, how the threat actors succeeded in breaching the organization, and what the consequences were. In addition to dissecting what went wrong, it’s important to review the available data to understand the lessons of exactly how and why data breaches happen, to avert—or at least mitigate—the impact of future breaches.

Moving from symptoms to causes: Understanding the why

It’s typical for data breach investigations to uncover several security controls that were not in place at the time of a breach. Breaches often involve a combination of contributing factors that expose human errors, including control design flaws, implementation errors, unpatched systems, etc. But why? Detective work is necessary to determine if the security environment and controls were designed improperly, maintained poorly or simply neglected—or any combination thereof. Did inadequate support processes allow security deficiencies to go unnoticed—or worse, noticed but uncorrected? For what seems to be just a few situations, countless additional “whys” crop up. Was the breached environment designed or implemented improperly because of poor staffing or lack of competence? Ineffective use of security tools is a common contributing factor; the tools may be in place, but the staff is not sufficiently trained to use the tools to effectively detect and respond to a security incident. Was a culture of indifference to compliance, quality and standards a factor?

In broad terms, the first objective of incident response is not to determine how and why the breach occurred; rather it’s to contain the breach and stop the data leak (although, sadly, sometimes our Verizon Threat Research Advisory Center (VTRAC) investigators have the additional task of asset discovery before the collection and analysis effort can be initiated). This is followed by determining the scope and full extent of the breach. Once these activities are completed, the focus can then shift to understanding how and why the breach happened, which controls failed or were not in place to begin with, and to what extent the not-in-place controls led or contributed to the breach. The investigating team then begins the journey of scrutinizing the control environment, working their way back through multiple layers of controls and constraints that impacted the effectiveness of the in-place defenses.

Peeling back the layers: Exposing cause-and-effect relationships

This inevitably leads to uncovering the differences between perception and reality—laying bare poor organizational management practices, operational design, and execution and monitoring deficiencies. Each can contribute to a weakened control environment. Most issues are symptoms that result from poor planning or failing to include them in a strategic plan, starting with inadequate leadership and ending with commitment, communication and culture issues. Such concerns are a combination of Verizon’s Top 7 Strategic Data Security Management Traps (see page 12 of the 2020 PSR). The focus then shifts toward presenting a clear understanding of the remediation steps needed to enhance the security posture to prevent—or at least mitigate—a repeat of the same or similar incidents. The end of a data breach investigation concludes with the presentation of a final management report documenting findings and recommendations. A good report and presentation include an overview of the critical decisions that were made and not made, and the initial key factors that contributed to control failures down the line. The process may also include presenting the findings and recommendations to the board. The presentation should describe, where possible, what the exact or most likely issues were that resulted in the security incident turning into a data breach. Understandably, the board should be most interested in the way forward—the corrective actions required. They are also interested in the critical processes and capabilities needed to achieve a level of security and compliance maturity needed to deliver a proven (assured) level of effectiveness and sustainability. Enabling this understanding is a somewhat daunting and complex endeavor.

With security breaches becoming increasingly common, experienced security professionals are simplifying the complexity of this communication. It requires distilling the presentation content down to root causes and main contributing factors, to clarify the goal of security and compliance that the organization actually pursued (expectations vs reality), and what contributed to conditions that resulted in a security compromise.

PCI DSS controls that lack reliability and sustainable effectiveness are, in most cases, merely a symptom of an organizational lack of commitment to specify a level of assurance that includes those performance qualities (reliability, effectiveness and sustainability in design and operation). These are necessary requirements and objectives of security and compliance goals and should be incorporated as key elements in the security strategy.

Be very explicit about what you are aiming for.

Any actions within a security and compliance strategy should be framed, directed and influenced by the set of goals and objectives you define and communicate.

This underscores the importance of why sustainable control effectiveness should be explicitly and clearly incorporated as a strategic objective and made part of the overall goal. Your goals and objectives and their necessary conditions create the framework for every decision, every action within your security and compliance posture. Spending time on goals, requirements and constraints is essential to create a supporting governance structure that can help ensure that decisions and actions undertaken by people within the organization don’t deviate from the strategy, goals and objectives that management determined to pursue. As is evident in the myriad of data breach investigation cases Verizon has conducted, failure to do so can set up a series of consequences that may result in unaddressed core conflicts, lack of focus, poor performance and eventually the nonachievement of goals.