The PCI-DSS Compliance Report

A key element of the PCI-DSS standard is Requirement 10: Track and monitor all access to network resources and cardholder data. Logging mechanisms and the ability to track user activities are critical in preventing, detecting and minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.

However the 2014 Verizon PCI Report is billed as an inside look at the business need for protecting payment card information says: “Only 9.4% of organizations that our RISK team investigated after a data breach was reported were compliant with Requirement 10. By comparison, our QSAs found 31.7% compliance with Requirement 10. This suggests a correlation between the lack of effective log management and the likelihood of suffering a security breach.”

Here is a side benefit of paying attention to compliance: Consistent and complete audit trails can also significantly reduce the cost of a breach. A large part of post-compromise cost is related to the number of cards thought to be exposed. Lack of conclusive log information reduces the forensic investigator’s ability to determine whether the card data in the environment was exposed only partially or in full.

In other words, when (not if) you detect the breach, having good audit records will reduce the cost of the breach.

Organizations can’t prevent or address a breach unless they can detect it. Active monitoring of the logs from their cardholder data environments enables organizations to spot and respond to suspected data breaches much more quickly.

Organizations generally find enterprise log management hard, in terms of generating logs (covered in controls 10.1 and 10.2), protecting them (10.5), reviewing them (10.6), and archiving them (10.7).

Is this you? Here is how you spell relief – SIEM Simplified.

PCI-DSS 3.1 is here – what now?

On April 15, 2015, the PCI Security Standards Council (PCI SSC) announced the release of PCI DSS v3.1. This follows closely on the heels of PCI DSS 3.0, that just went into full effect on January 1, 2015. There is a three-year cycle between major updates of PCI DSS and, outside of that cycle, the standard can be updated to react to threats as needed.

The major driver of PCI DSS 3.1 is the industry’s conclusion that SSL version 3.0 is no longer a secure protocol and therefore must be addressed by the PCI DSS.

What happened to SSL?
The last-released version of encryption protocol to be called “SSL”—version 3.0—was superseded by “TLS,” or Transport Layer Security, in 1999. While weaknesses were identified in SSL 3.0 at that time, it was still considered safe for use up until October of 2014, when the POODLE vulnerability  came to light. POODLE is a flaw in the SSL 3.0 protocol itself, so it’s not something that can be fixed with a software patch.

Bottom line
Any business software running SSL 2.0 or 3.0 must be reconfigured or upgraded.
Note: Most SSL/TLS deployments support both SSL 3.0 and TLS 1.0 in their default configuration. Newer software may support SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. In these cases the software simply needs to be reconfigured. Older software may only support SSL 2.0 and SSL 3.0 (if this is the case, it is time to upgrade).

How to detect SSL/TLS usage and version?
A vulnerability scan from EventTracker Vulnerability Assessment Service (ETVAS) or other scanner, will identify insecure implementations.

SSL/TLS is a widely deployed encryption protocol. The most common use of SSL/TLS is to secure websites (HTTPS), though it is also used to:
• Secure email in transit (SMTPS or SMTP with STARTTLS, IMAPS or IMAP with STARTTLS)
• Share files (FTPS)
• Secure connections to remote databases and secure remote network logins (SSL VPN)
SIEM Simplified customers
The EventTracker Control Center will have contacted you to correctly configure the Windows server instance hosting the EventTracker Manager Console, to comply with the guideline. You must upgrade or reconfigure all other vulnerable servers in your network.

If you subscribe to ETVAS, the latest vulnerability reports will highlight any servers that must be reconfigured along with detailed recommendations on how to do so.

100 Log Management uses #57 PCI Requirement XII

Today we conclude our journey through the PCI Standard with a quick look at Requirement 12. Requirement 12 documents the necessity to setup and maintain a policy for Information Security for employees and contractors. While this is mostly a documentation exercise it does have requirements for monitoring and alerting that log management can certainly help with.

100 Log Management uses #56 PCI Requirements X and XI

Today we look at the grand-daddy of all logging requirements in PCI — Section 10 (specifically, Section 10.5) and Section 11. As with most of PCI, the requirements are fairly clear and it is hard to understand how someone could accomplish them without log management.

100 Log Management uses #55 PCI Requirements VII, VIII & IX

Today we look at PCI-DSS Requirements 7, 8 and 9. In general these are not quite as applicable as the audit requirements in Requirement 10 which we will be looking at next time, but still log management is useful in several ancillary areas. Restricting access and strong access control are both disciplines log management helps you enforce.

100 Log Management uses #54 PCI Requirements V & VI

Last we looked at PCI-DSS Requirements 3 and 4, so today we are going to look at Requirements 5 and 6. Requirement 5 talks about using AV software, and log management can be used to monitor AV applications to ensure they are running and updated. Requirement 6 is all about building and maintaining a secure network for which log management is a great aid.

-By Ananth

100 Log Management uses #53 PCI Requirements III & IV

Today we continue our journey through the Payment Card Industry Data Security Standard (PCI-DSS). We left off last time with Requirement 2, so today we look at Requirements 3 and 4, and how log management can be used to help ensure compliance.

-By Ananth

PCI-DSS under the gun

Have you been wondering how some of the statements coming from the credit card processing industry seem a little contradictory? You hear about PCI compliant entities being hacked but the PCI guys are still claiming they have never had a compliant merchant successfully breached. Perhaps not, but if both statements are true, you certainly have an ineffective real world standard or problematic certification process at the very least.

Not to pick on Heartland again but Heartland passed their PCI mandated audit and were deemed compliant by a certified PCI Auditor approximately one month prior to the now infamous hack. Yet, at Visa’s Global Security Summit in Washington in March, Visa officials were adamant in pointing out that no PCI compliant organization has been breached.

Now, granted, Heartland was removed from their list of certified vendors after the breach although perhaps this was just a bizarre Catch 22 in play – you are compliant until you are hacked, but when you are hacked the success of the hack makes you non-compliant.

Logically it seems 4 things or a combination of the 4 could potentially have occurred at Heartland. 1) The audit could have been inadequate or the results incorrect leading to a faulty certification. 2) Heartland in the intervening month made a material change in the infrastructure such that it threw them out of compliance. 3) The hack was accomplished in an area outside of the purview of the DSS, or 4) Ms. Richey (and others) is doing some serious whistling past the graveyard.

What is happening in the Heartland case is the classic corporate litigation-averse response to a problem. Anytime something bad happens the blame game starts with multiple targets, and as a corporation your sole goal is to be sure to get behind one or the other (preferably larger) target because when the manure hits the fan the person in the very front is going to get covered. Unfortunately this behavior does not seem to really foster solving the problem as everyone has their lawyers and are not talking.

Regardless, maybe the PCI should not be saying things like “no compliant entity has ever been breached” and maybe say something like “perhaps we have a certification issue here”, or “how do we reach continuous compliance?” or even “what are we missing here?”

-Steve Lafferty

100 Log Management uses #52 PCI Requirement I & II – Building and maintaining a secure network

Today’s blog looks at Requirement 1 of the PCI Data Security Standard, which is about building and maintaining a secure network. We look at how logging solutions such as EventTracker can help you maintain the security of your network by monitoring logs coming from security systems.

-By Ananth

100 Log Management uses #51 Complying with PCI-DSS

Today we are going to start a new series on how logs help you meet PCI DSS. PCI DSS is one of those rare compliance standards that call out specific requirements to collect and review logs. So in the coming weeks, we’ll look at the various sections of the standard and how logs supply the information you need to become compliant. This is the introductory video. As always, comments are welcome.

– By Ananth