Brian Pennington

A blog about Cyber Security & Compliance



Merchants are complacent about PCI DSS, report reveals.

Verizon logo
Image via Wikipedia

Verizon have launched their 2011 Payment Industry Compliance Report which draws on their experiences as a QSA company and previous annual reports.

Extracts from the report are below.

Unchanged from last year, only 21 % of organizations were fully compliant at the time of their Initial Report on Compliance (IROC). Verizon commented with “This is interesting, since most were validated to be in compliance during their prior assessment”.

  • Organizations met an average of 78% of all test procedures at the IROC stage
  • 20% of organizations passed less than half of the DSS requirements
  • 60 % scored above the 80 % mark

Organizations struggled most with the following PCI requirements:

  • 3 (protect stored cardholder data)
  • 10 (track and monitor access)
  • 11 (regularly test systems and processes)
  • 12 (maintain security policies).

The PCI Requirements showed the highest implementation levels were:

  • 4 (encrypt transmissions over public networks)
  • 5 (use and update anti-virus)
  • 7 (restrict access to need-toknow)
  • 9 (restrict physical access)

Organizations do not appear to be prioritizing their compliance efforts based on the PCI DSS Prioritized Approach published by the PCI Security Standards Council even less so than in the previous year.

A mini-study comparing governance practices to the initial compliance score suggests that the way organizations approach compliance significantly factors into their success.

Once again, organizations that suffered data breaches were much less likely to be compliant than a normal population of PCI clients. Analysis of the top threat actions leading to the compromise of payment card data continues to exhibit strong coverage within scope of the PCI DSS. For most of them, multiple layers of relevant controls exist across the standard.

In the pool of assessments performed by Verizon QSAs included in this report

  • 21% were found fully compliant at the completion of their IROC
  • This is just 1% less than in their last report, and effectively the same number

The lack of change is a disappointing, as many in the industry were hoping to see an increase in overall compliance as the PCI DSS became more familiar to an increasing number of organizations.

79% of organizations were not sufficiently prepared for their initial assessment

Having established that only 21% “passed the test” the next question becomes “what was their score?”

  • On average, organizations met 78% of all test procedures defined in the DSS at the time of their IROC.
  • Down 3% from Verizon’s last report; but again, the difference is nominal.

Therefore, the baseline set by the PCI DSS must not reflect the baseline set by the companies themselves. For most organizations, to achieve compliance they must do things they were not previously doing (or maintaining).

Another common Achilles heel of merchants and service providers in the PCI assessment process is over confidence

 “It was painful, but we made it through last year, so this year should be a breeze”

is a typical sentiment with which many organizations approach the yearly assessment. That can be a costly mistake. When the QSA arrives on-site, a mere 1/5th of businesses are found to be compliant, even when given the extra time between the on-site visit and completion of the IROC.

Complacency and fatigue are two additional drags that make maintaining compliance year over year difficult. Too many businesses approach PCI from the point of view that “what was good enough last year will be good enough this year.” But unless someone’s been babysitting a process, such as documenting and justifying all services allowed through the firewalls, things can easily be forgotten in the haste to get business done.

When examining the percentage of organizations passing each requirement at the IROC phase.

  • Some requirements show percentages dipping below 40%, while others exceed the 70% range.
  • Six of the twelve show an increase over last year, and the average is up two points.
  • However, the average number of test procedures met within each requirement is down 4%.
  • None of these numbers is indicative of a clear change given the size and makeup of the dataset, but it certainly reinforces the notion that
  • organizations continue to struggle (at varying degrees) in all areas of the DSS.

How do organisations perform against the 12 Requirement? The four highest rated Requirements are:

  • 4 (encrypt transmissions)
  • 5 (AV software)
  • 7 (logical access)
  • 9 (physical access)

Requirement 10 (tracking and monitoring) boasted the highest gain+13 %

Requirement 5 (AV software) may lose its place in the top three, which is an odd development, since AV software has for so long been among the most basic and widespread of security controls.

Requirement 4 (encrypt transmissions) showed a marked improvement which may indicate that administrators are deciding it’s easier to direct all Internet traffic containing credit card data over SSL.

Requirement 7 (logical access) showed a slight improvement, which could mean more strict attention is being paid to who is given access to cardholder data.

Requirements 3 (stored data) and 11 (regular testing) are once again in the bottom tier, while Requirement 12 (security policies) ousted 10 (tracking and monitoring) from the bottom. This suggests that the encryption of data at rest continues to be a major headache for organizations, especially the more detailed portions, such as annual key rotations.

Requirement 11’s low showing reminds us why ‘set and forget is a very bad bet’ should be a core mantra of the security profession. The fact that security policies rank among the lowest of the low is not a good sign since policy drives practice.

Requirement 1 remains virtually unchanged since last year, at 44% compliance, compared to the 46% in the last report. Only 63% of companies met Requirement 1.1.5 regularly

Compliance is the continuous state of adhering to the regulatory standard. In the case of the PCI DSS there are daily (log review), weekly (file integrity monitoring), quarterly (vulnerability scanning), and annual (penetration testing) activities that an organization must perform in order to maintain this continuous state of compliance

The entire report can be found on the Verizon web site here.


Could you save 50% on the cost of your Firewall Change Requests?

Tufin, a “Security LifeCycle Management solutions company” claim that with effective Firewall change management a business could reduce the cost of its Firewall management by 50%.

Tufin use research from Frost and Sullivan to support their claim.

Frost & Sullivan reports that “The process of implementing a change request to a firewall is a combination of many tasks that are in most cases manual, unclear and time-consuming. [Tufin] SecureChange TM Workflow automates the request process, substantially reducing the overall IT costs associated with change requests by half annually.”

What is undeniable is the need for effective change management processes and controls for Firewalls if a Firewall, or any other security solution, is to remain efficient and secure.

Firewall change management is a mandated requirement in several legislative and compliance standards, for example the Payment Card Industry Data Security Standard (PCIDSS) has a list of specific controls that should be in place and should be provable, a sample list from the standard is below:

1.1 Obtain and inspect the firewall and router configuration standards and other documentation specified below to verify that standards are complete. Complete the following:

1.1.1 Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations.

1.1.2.a Verify that a current network diagram (for example, one that shows cardholder data flows over the network) exists and that it documents all connections to cardholder data, including any wireless networks.

1.1.2.b Verify that the diagram is kept current.

1.1.3.a Verify that firewall configuration standards include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone.

1.1.3.b Verify that the current network diagram is consistent with the firewall configuration standards

1.1.4 Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components.

1.1.5.a Verify that firewall and router configuration standards include a documented list of services, protocols and ports necessary for business—for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.

1.1.5.b Identify insecure services, protocols, and ports allowed; and verify they are necessary and that security features are documented and implemented by examining firewall and router configuration standards and settings for each service.

1.1.6.a Verify that firewall and router configuration standards require review of firewall and router rule sets at least every six months.

1.1.6.b Obtain and examine documentation to verify that the rule sets are reviewed at least every six months.

1.2 Examine firewall and router configurations to verify that connections are restricted between untrusted networks and system components in the cardholder data environment, as follows:

1.2.1.a Verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented.

1.2.1.b Verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit “deny all” or an implicit deny after allow statement.

1.2.3 Verify that there are perimeter firewalls installed between any wireless networks and systems that store cardholder data, and that these firewalls deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.

1.3 Examine firewall and router configurations—including but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment—to determine that there is no direct access between the Internet and system components in the internal cardholder network segment

1.3.6 Verify that the firewall performs stateful inspection (dynamic packet filtering). (Only established connections should be allowed in, and only if they are associated with a previously established session.)

1.4.a Verify that mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), and which are used to access the organization’s network, have personal firewall software installed and active.

1.4.b Verify that the personal firewall software is configured by the organization to specific standards and is not alterable by users of mobile and/or employee-owned computers.

6.6 For public-facing web applications, ensure that either one of the following methods are in place as follows:

  •  Verify that public-facing web applications are reviewed (using either manual or automated vulnerability security assessment tools or methods), as follows:
  •  Verify that a web-application firewall is in place in front of public-facing web applications to detect and prevent web-based attacks.

The day to day operation of a business can mean “quick changes” are made to firewalls and other security solutions and are not be recorded but could significantly impact on the businesses security level and the organisation’s ability to maintain compliance.

A spreadsheet could be an answer but configuration changes often involve several tasks, for example testing the change prior to going live. Changes across multiple devices may involve several people as security devices need highly skilled security professionals to manage them. Without an effective process or solution an organisation could be wasting the time of expensive resources and may incur unexpected and costly downtime.

To meet these challenges in a cost-effective manner, Tufin recommends that organizations need to extend IT automation into the domain of network security configuration. Automating the security change lifecycle can help companies to: 

  • Improve network security and uptime
  • Enforce corporate governance
  • Manage risk effectively and proactively
  • Increase operational efficiency
  • Comply with industry and regulatory standards
  • Audit security infrastructure quickly and accurately
  • Improve service levels

Tufin believe the key to effective security change automation solution is a combination of both workflow and security technologies. Generic ticketing and helpdesk systems can route requests to security administrators, but since they have a limited understanding of security processes and compliance policies, they cannot automate and enhance each of the stages in a configuration change, from request and design, through implementation and auditing. A comprehensive security change automation solution will work either alone, or in concert with a standard ticketing system, to provide: 

  • Multiple, customizable change workflows tightly coupled with security and network infrastructure, directory services and compliance policies
  • Automated, proactive risk and compliance analysis as an integral part of the change process
  • Configuration change advisory and automatic verification to reduce the risk of errors and shorten ticket resolution time
  • Separation of duties and enforcement of IT governance
  • A comprehensive audit trail with integrated reporting
  • SLAtracking and high-level monitoring tools to ensure continuous improvement 

The security change lifecycle represents a holistic view of an organization’s security configuration change processes.

A typical security change lifecycle could include the following stages: 

Request: A business user requests a service, most commonly access to an application or network, or IT requests connectivity changes for a new or modified server or application. 

Business Approval: The request is sent for approval to an IT manager to ensure that it is justified. 

Technical Design: An engineer translates the request from its business context into a specific implementation plan on the affected firewalls or devices. 

Risk Analysis: A security manager performs risk analysis and checks the change for compliance. 

Implementation: The change is actually implemented on the network infrastructure by one or more administrators. 

Verification: The user checks that his/her request has been fulfilled. At this stage, a manager can also verify that the implementation was in accordance with the approved design. 

Audit: Periodically, all changes must be audited in order to demonstrate sufficient security levels and compliance with standards. 

Other firewall solutions are available from companies like Firemon and many Firewall vendors have introduced their own solutions for example Check Point. 

Download the Tufin White Paper here.


Benefits of PCI Compliance – direct and indirect

Credit cards
Image via Wikipedia

Many Merchants see the Payment Card Industry’s Data Security Standard (PCI DSS) as an expense they could do without. 

The counter argument is most businesses would struggle if nothing was done to tackle Credit Card Fraud because the Credit Card companies would need to charge Merchants a higher transaction rate to cover their losses. 

So, what other reasons could there be for becoming PCI Compliant? 

The answer very much depends on your business type and the loyalty of your customers and prospective customers. 

Some very good reasons for becoming PCI compliant are listed below.

Continue reading “Benefits of PCI Compliance – direct and indirect”

Blog at

Up ↑

%d bloggers like this: