Periodic PCI Compliance Activities

I am often asked what are the activities companies must perform between PCI assessments in order to remain compliant with the PCI standard. Many people would be surprised to find out that the PCI DSS outlines the specific tasks companies must be doing all the time. The following activities were taken directly from the PCI DSS Version 1.2.1 and outline the periodic procedures companies must take to stay compliant:

Annually

3.6.4 Periodic cryptographic key changes:

• As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically
• At least annually

6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.
• Installing a web-application firewall in front of public-facing web applications.

9.5 Store media back-ups in a secure location, preferably an off-site facility such as an alternate or backup site or a commercial storage facility. Review the location’s security at least annually.

9.9.1 Properly maintain inventory logs of all media and conduct media inventories at least annually.

11.3 Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification.

12.1.2 Annual process that identifies threats, vulnerabilities, and results in a formal risk assessment.

12.1.3 Perform a Security Policy review at least once a year and update when the environment changes.

12.6.1 Educate employees upon hire and at least annually.

12.6.2 Require employees to acknowledge at least annually that they have read and understood the company’s security policy and procedures.

12.9.2 Test Incident Response Plan at least annually.

Bi-Annually

1.1.6 Review firewall and router rule sets at least every six months.

Quarterly

8.5.5 Remove/disable inactive user accounts at least every 90 days.

8.5.9 Change user passwords at least every 90 days.

9.1.1 Use video cameras or other access control mechanisms to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law.

11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploy a wireless IDS/IPS to identify all wireless devices in use.

11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

Weekly

11.5 Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files or content files; and configure the software to perform critical file comparisons at least weekly.

Daily

10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).

12.2 Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures).

Immediately

8.5.3 Set first-time passwords to a unique value for each user and change immediately after the first use.

8.5.4 Immediately revoke access for any terminated users.

12.3.9 Activation of remote-access technologies for vendors only when needed by vendors, with immediate deactivation after use.

Not specified, but suggest annually

12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status.

Read more!

Securing a PCI compliant vendor

Seven restaurants are suing Radiant Systems and Computer World for producing and selling insecure systems that led to security breaches, which then led to fines and other costs for the breached companies.

The restaurants claim that they were sold a product that was not PCI compliant, and the two vendors should be held responsible for the data lost and the money spent as a result of the breach.

Radiant Systems is a point of sale terminal company and Computer World is the company that sold and maintained the Radiant Systems product. The question is, should the vendors or the restaurants be held responsible for the data breach? After reading a blog that left the matter undetermined, it was necessary to clear up the confusion.

First off, a ROC or SAQ from the restaurants must have signed off on the product. As a certified QSA, the first thing we would do is check the PCI list to ensure that the product is listed. The point of sale system is certified by version. While version 1.0 of the product may be certified, 1.5 may not be. The restaurants should have spent the time and money to determine that the vendors and the products purchased would be keeping their company data secure, and they clearly did not.

Anyone can say they are PCI compliant. It's a very lucrative business right now, and many people are falsely claiming compliance to make money. As a business who is interested in hiring a vendor to provide or implement a product, it is your responsibility to research the vendor and choose the best product. Ultimately, the fault falls upon the breached restaurants.

An easy way to prevent situations like this in your company:

• Look at the PCI list. PCI provides an Approved Service Provider list that includes products, product versions and the codes used. Before bringing in any vendor to your company, check the list to be sure their product is PCI compliant.

Read more!

Check, Please!

One of the most intriguing stories in the security world today is the lawsuit Merrick v. SAVVIS in which Merrick stipulates that SAVVIS is liable for lack of diligence on an audit of CardSystems, on which Merrick relied. This groundbreaking lawsuit could change the liability landscape, allowing assessors to be sued by indirect third parties. Prior to the more formal PCI DSS program, there were many suspicions of rubber stamp audits occurring. But even today, we see organizations pushing for the cheapest audit they can do and still get the passing “check” mark. It’s this minimum approach to security we’ve often called “malicious compliance” that leads to a lack of quality and a greater risk of breach.

Just for some more background, SAVVIS had certified CardSystems Solutions as compliant under the VISA CISP program (predecessor to PCI DSS). During a breach of CardSystems, approximately 40 million cardholder data records were compromised. At that time, this was one of the biggest breaches recorded. The forensics investigation concluded that the CardSystems firewall was not compliant and that records were not being encrypted as they should be. The big debate at this point will be to determine if SAVVIS did enough due diligence at the time or if CardSystems possibly withheld any information from the auditor.

I think that last sentence is really what irks me about the relationship between an auditor and an organization. I completely understand and agree for the need of ethical independence between both parties. But I am frustrated when it creates such a wall and lack of collaboration that the auditor just becomes someone to fill in check boxes. Then the organization takes an adversarial approach in which they ‘speak only when spoken to’ and hope the auditor doesn’t uncover the dirty little secrets of what isn’t working. It’s when something isn’t working right that a breach occurs.

So when looking for an auditor, I think it’s important that organizations make a conscious, formal decision on what they are looking for. It’s the old Chinese proverb, “Be careful what you wish for since you might just get it”. If it’s a check mark approach, then understand that may be all you are getting. You aren’t getting a consultant or an advisor. On the other hand, if you are looking for a auditor who isn’t just working off a checklist but is truly interested in your organization’s risk, then you can end up with a partner that can provide a whole lot of value, not just for compliance but also for security, since the two aren’t the same.

I guess the whole point of this exercise is to step back and take a look at your organization’s approach to the quality of the security program. The most common approach is following the “Plan, Do, Act, Check” lifecycle. As a pure security assessment firm, we feel very strongly that there needs to be a big emphasis on the “Check” step, so much that we put it first. No matter what step you are performing, you need to do it well if you want quality improvement. Security is not a very forgiving practice as a misstep in quality can quickly lead to incidents, then the blame game, then someone’s job. That’s not to say that quality is costly. But cheap certainly is. So the next time you place an ‘order’ for an auditor, think twice when you ask for the check.

Read more!

SecureState Attends PCI Compliance Seminar with ISACA

Craig Monastra of Sterling Jewelers with Brian Telesz and Nicole McClain of SecureState

Today, ISACA’s membership—more than 86,000 strong worldwide—is characterized by its diversity. Members live and work in more than 160 countries and cover a variety of professional IT-related positions inlcuding but not limited to IS auditor, consultant, educator, IS security professional, regulator, chief information officer and internal auditor.

SecureState's Brian Telesz and Nicole McClain (pictured above with Craig Monastra of Sterling Jewelers) attended the most recent ISACA seminar at Harry's Steakhouse for good food and a great presentation on PCI Compliance. Keynote speaker was Lisa Peterson of Progressive Insurance.

The Information Systems Audit and Control Association is primarily focused on promoting quality IS audit and governance education to its members. The IS audit profession is based and dependent upon technological expertise. With Audit and Compliance being one of SecureState’s four divisions of expertise its helps our consultants and directors keep abreast on the latest hot topics, concerns and trends in the IT audit world. SecureState is a leader in the Audit and Compliance world. We engage in many different environments such as finance, insurance, manufacturing, retail and energy which gives us a very diverse expertise in the many compliances and security regulations that companies need to adhere to.

In addition to the importance of Audit and Compliance, SecureState belongs to the local chapter and attends the monthly meetings to keep SecureState in front our current and prospective clients who are members. We will also speak and present at these monthly meetings which helps educate ISACA chapter members on what SecureState sees out in the field during engagements and clarify and educate on IT audit issues.

Would you like SecureState to speak at your next event? Contact SecureState at 800.903.6264 for more information.

Read more!

"So What's Everyone Else Doing???"

As a security auditor, I can't tell you how many times I've been asked this when talking about compliance. If I only had a nickle for every time someone asked me that question... well... I'd probably want to throw it at the person who just asked me it. This is such a bad question on so many levels and it still frustrates me each time. That being said, I suppose I should answer it here so that maybe, just maybe, they won't ask next time.

My first response is, 'everyone else' is not doing a good job, not enough, and likely the wrong things. For example, take PCI compliance. Even after all this time, only 77% of Level 1 Merchants are compliant. Now if everyone is being as tough as they should be, those merchants are getting fined $25,000 per month and a possibly higher transaction rate. Compliance basically exists because when 'everyone else' was doing what 'everyone else' did, 'everyone' sucked! So somebody had to step in and raise the bar for them. It's like the flock needing a shepherd.

Now imagine that all of sudden you get breached because your 'average' organization is doing things just like 'everyone else,' which isn't enough... do you really want to stand at the podium and state that you didn't do enough because others aren't? Is that really a good, defensible position? On average, the average isn't good. So do you really want to measure yourself against them?

I think it's also ironic when you realize that just prior to this question is the statement made by the same person that "Well, we're unique here at Company X". Of course you are! If not, I can't imagine you'd have differentiators and be unique. There is no reason why that can't be security. It is probably a pretty good reason to not be like 'everyone else'. I'm hoping the next time someone asks me this, they want to know so they can use it for out marketing 'everyone else'.

Read more!

Regulations Attack

I recently published top eight trends for 08’ (http://www.securestate.com/Pages/Top-8-In-08.aspx), however one topic in particular has caught my attention, why are “Regulations” being attacked?

At DefCon 16 I had the opportunity to meet some really interesting people who had different perspectives on security. However, for the first time in DefCon history (to my knowledge) “Compliance” standards opened the conference Friday morning. I was so excited to hear what the “hackers” thought about PCI, GLBA, HIPAA etc. To my disappointment, the presenter ranted about how compliance doesn’t equal security… DUH! But what they do is provide some value and the value is called “doing something!” Hell, most companies (97%) won’t do anything at all until they are forced!

Even with these standards, millions of records are still being compromised. Let’s rant about companies losing our data, not about how bad the regulations are. Let’s face it, if companies were doing what they should, there wouldn’t be a need for regulations! I am writing an article for Information Week on Malicious Compliance in Distress, which addresses companies doing the bare minimum to become compliant, instead of appropriately securing the data. If you use these regulations as a Minimum Security Baseline, you can always add additional layers of security to these regulations. For example… PCI just calls out not using WEP, but mentions the ability to use WPA and WPA2… however as security professionals we would consider WPA and WPA2 just as bad. So by PCI standards you can be compliant, however not any more secure than if you used WEP. Use the regulations to get a new stronger encryption protocol for your wireless environment.

Let’s not attack the regulations, but the reason why they were developed! View regulations as the minimum standard. If you took a comprehensive approach to security you would comply to all the regulations anyways (ISO 27001 & 27002). So instead of bitching out regulations… use them to get funding and do the right thing :-)

Read more!

PCI Compliance: Close but no cigar.

PCI Compliance is on almost everyone's mind and it will continue to grow in popularity as time progresses. Before I start, this is by no means a rant or flaming of the PCI DSS 1.1 standard, in fact, to date the PCI DSS is the most technical security framework really out there to date. There are a lot of positives toward the standard; however it has many shortcomings. I'm not going to list every one, but focus on some of the most pressing issues that we've seen as penetration testers and where the standard really is failing.

First, let’s start with: the standard should never be fully relied upon for organizations overall security posture. A matured security organization typically pulls from many standards like the ISO 27001/27002, NSA IAM, NIST, PCI, etc. One thing that this standard has really pulled through was a start to security in organizations and a start for security to be taken seriously. Generally, banks were the forefront for protecting data due to the sensitive nature of information, and most other organizations security fell in the wind and has since begun to shift in a different direction.

As a penetration tester, and running a team of gifted hackers, we get to see every environment and configuration known to man. Due to PCI's 11.3 "Performing penetration testing at least one a year", we do a variety of penetration testing assessments against PCI Compliant organizations. One of the most alarming statistics is our 63 percent success rate for breaching systems in PCI Compliant organizations. By breaching systems, we're talking about full access to the underlying operating system and potential to further penetrate into the network. The 63 percent doesn't even include access to the back-end databases, login bypasses, and various other issues we find during a pentest.

PCI's 1.1 states in 6.5 to use the OWASP guidelines for securing their systems. PCI 1.1 uses the OWASP 2004 framework for vulnerabilities, which is missing the good ol' malicious file execution amongst others. In addition to this, the ASV scans that need to be performed only check for XSS and SQL Injection. Vulnerability scanners, in general, are pretty rudimentary and basic in vulnerability identification, but only detecting two of the overall top ten is a major issue. In 6.6 a code review or WAF has to be in place, which should hopefully stop SOME of these attacks, but the alarming issue here is we've done successful penetration tests against sites that have undergone a code review, or have a WAF in place and do minor protection against attacks.

WAF are great (if properly configured), don't get me wrong, but they should not be the only layer of defense. Creating a security systems development life-cycle (SSDLC) from the beginning of development and through development and establishing code freezes for security testing before going into production is vital and the preferred method. Web applications have been getting a bum rap and are the major points of entry for external breaches to date. The standard simply states "Installing an application-layer firewall in front of web-facing applications", it does not state anything about allowing exceptions for functionality of the site (and introducing exposures) or hardening techniques. Again, the purpose of the standard was not to secure your systems for you, but at least give you a framework for organizations to implement security.

My next question on the DSS standard is who performs the code reviews looking for these common vulnerabilities? Most VARs have a penetration testing wing, generally consisting of two people that implement product and do penetration testing as a side job (oh and hey, if you buy this product it'll fix your vulnerabilities). These guys generally use tools that don't even touch the web application layer in depth and give false satisfactions and assurance to organizations. There’s no certification process for web applications assessors, it only states "an organization that specializes in application security", if I have Nessus does that make me a specialist in web application security? If I have AppScan, WebInspect, Ounce, Fortify, or any of the others in there, does running a tool make me a specialist?

My last main issue covers the ASV guidelines, quoted directly from the ASV scanning standard:

"Merchants and service providers have the ultimate responsibility for defining the scope of their PCI Security Scan, though they may seek expertise from ASVs for help. If an account data compromise occurs via an IP address or component not included in the scan, the merchant or service provider is responsible. "

We've run into many scenarios where organizations are using this loophole to take systems out of scope for the PCI assessment. While the organization is "responsible" if it becomes compromised, generally the companies we're seeing this as a way to pass the test without ever having any of the security restrictions on the system in place. So as per this statement, a main e-commerce site handling all credit card transactions for the organization can be taken out of scope by the merchant or service provider if they choose. At this point, what is the point in becoming compliant at all? Why study hard for a “C” when you can get an “A” every time without ever studying? “Sure if you get caught cheating its bad, but what’s the payoff, we're never going to get breached!”

To finalize the point I was trying to get out here is organizations are really using this to become "secure", when that really isn't the impact intended. In order for organizations to incorporate security, it has to be a widespread adoption within the organization, pull multiple frameworks and standards, and incorporate them into a regularly tested and updated programs. Relying solely on of PCI compliance and going through the checklist is not going to protect you from a breach by any means.

Read more!