Photo: tricky ™ on Flickr.

Found an interesting article by Martin McKeay through “Security Bloggers Network” which discusses PCI compliance and the implications of hosting applications and data in the cloud.

He boils everything down to one simple point; If you store/transmit/handle cardholder data in a service provider’s network, that network becomes part of the cardholder data environment and needs to be PCI compliant:

“So I made several comments on the post, most of which boil down to referencing PCI requirement 12.8: If you’re sharing cardholder information, i.e. credit card numbers, with a third party service provider, you need to have a clause in your contract that makes the service provider responsible for the PCI compliance of their systems. With the example given, Amazon’s EC2, the chances of getting such a clause in your contract are almost non-existent.”

A subject similar to this has been of interest for me before as Panda MalwareRadar is a cloud service where files deemed interesting are ‘fingerprinted’. Those fingerprints are then communicated to our Collective Intelligence servers in order to be analyzed deeper. For more info on CI, see this whitepaper by Panda Research.

In other words no complete files ever leave the client’s network, but some clients that are in the process of becoming PCI compliant are unsure of what implications services such as this might have. Their general feeling is that they aren’t 100% comfortable handing out fingerprints of possibly malicious processes or files, as it might (theoretically at least) be a false positive. This will lead to unforeseen information disclosure to a third party (PandaLabs and CI servers). We also do inventory of the current patchstatus with the same tool and the same thing goes for that.

I trust our systems with the information gathered, but I understand their position as well as they have to be able to prove compliance. But is there any need to worry?

It all seems to come down to two questions; “Can you trust your security vendor?” and “What requirements in PCI DSS might be implicated by this type of services?”.

Personally I think that some level of trust must exist between a security vendor and their customers so for me the answer to the first one is Yes. Many security products and services are placed in such sensitive locations that it would be impossible to use them otherwise (not only talking about anti-malware here).

I’m unsure about the second one though and would appreciate any comments on this. From what I’ve been able to find information on, there really shouldn’t be any problems. The one thing that might be troubling is the patchstatus information, but the information sent can be anonymized to not include data such as computernames or IP-adresses so that you only get an overview of the current situation (same goes for the malware detections).

Any PCI DSS experts that feel like commenting on what their experiences are with Collective- or Herd-intelligence technologies and services such as this?

EDITED TO ADD: Mike at Aegenis comments below and recommends reading his follow-up post.

PciAnswers.com (Aegenis Group) posted today on the differences in PCI DSS version 1.1 and 1.2.

For me personally as a consumer, I appreciated seeing deadlines being set for WEP usage.

* New implementations of WEP are not allowed after March 31, 2009
* Current implementations must discontinue use of WEP after June 30, 2010

WEP is seriously dead and dangerous technology and should not be used in or within reach of a network containing cardholder data. Remember some years ago, when people used to sit outside WalMart and sniff CC-data?

The deadlines seem to be a bit too far into the future though, but my guess is that the time is needed for the larger merchants in order to change legacy devices. On the other hand, this should already have been done years ago.

When it comes to Requirement 5, the anti-virus one, they note something I discarded in earlier posts:

* At first glance it appears that version 1.2 reverts to an older form of the standard by mandating “anti-virus software applies to all operating system types” but it quickly clarifies the intent still as those systems “commonly affected by malicious software.” Although the reference to UNIX is removed, it does state that companies should deploy on such systems “if applicable anti-virus technology exists.”

Requirement 10 has also been modified and now mandates that you retain your logs for at least one year, with the last three months available for immediate analysis. In other words you can rotate away your logs to an archiving facility after three months and just keep the current data in your live logservers.

For me, and all Panda Security business & enterprise customers, this means modifying the variables for the built-in log retention even further. Previously we’ve extended the period only to three months to prevent excessive information in the console (which makes it sluggish) together with syslog logging which has been rotated according to the company at hand’s internal routines.

A lot of more news was presented and is available in an easily readable format at pcianswers.com.

From Branden Williams (Verisign):

“[...] Seriously though, are you ready? Version 1.1 has been around for over two years now (birthday was September 7, 2006), and by now you should have been able to validate as compliant to that version of the standard. If you are still struggling with 1.1, there is good news along with the bad. [...]“

Linked to it before but here is is again, PCI DSS 1.2 summary of changes.

For us in the AV business, the primary news are:

Requirement 5: Use and regularly update anti-virus software
- Clarified that requirement for use of anti-virus software applies to all operating system types
- Clarified that anti-virus software must address all known types of malicious software

Feels nice that they declare more directly that anti-virus (incorrect terms according to me) should be able to detect all types of malicious software. That is, they have to be Anti-Malware products (which is the “correct” term).

I was browsing the intertubes using an open WLAN when i stumbled on this article on Bakmans blog. The entry itself is a bit outdated but it got my brain working a bit.

Engaged in a search for more information on the subject and eventually found this paper (PDF – Aegis PCI DSS Wireless FAQ) through a pcianswers.com post.

One interesting, if not obvious, thing mentioned is that objective 11.1 require you to audit your sites for wireless networks even though you aren’t running any. This requirement comes from the possibility of rouge Access Points placed in the network(s) that handle card transactions, or a net that is trusted by it. You are not permitted to allow any rouge AP’s if you want to be or stay compliant.

Requirement 11.1 reads:
11.1 Test security controls, limitations, network connections, and restrictions annually to assure the ability to adequately identify and to stop any unauthorized access attempts. Use a wireless analyzer at least quarterly to identify all wireless devices in use.

And this control objective is applicable to all organizations that are aiming at PCI DSS compliance. The paper mentioned above has some of Aegis frequently asked questions on this listed and before you start asking expensive consultants, give it a read

The other control objectives discussed in the paper (including FAQs) in relation to wireless networking are:

4.1.1 For wireless networks transmitting cardholder data, encrypt the transmissions by using WiFi protected access (WPA or WPA2) technology, IPSEC VPN, or SSL/TLS. Never rely exclusively on wired equivalent privacy (WEP) to protect confidentiality and access to a wireless LAN. If WEP is used, do the following:
• Use with a minimum 104-bit encryption key and 24 bit-initialization value
• Use ONLY in conjunction with WiFi protected access (WPA or WPA2) technology, VPN, or SSL/TLS
• Rotate shared WEP keys quarterly (or automatically if the technology permits)
• Rotate shared WEP keys whenever there are changes in personnel with access to keys
• Restrict access based on media access code (MAC) address.
[...]
10.5.4 Copy logs for wireless networks onto a log server on the internal LAN.
[...]
1.3.8 Installing perimeter firewalls between any wireless networks and the cardholder data environment, and configuring these firewalls to deny any traffic from the wireless environment or from controlling any traffic (if such traffic is necessary for business purposes)
[...]
2.1.1 For wireless environments, change wireless vendor defaults, including but not limited to, wired equivalent privacy (WEP) keys, default service set identifier (SSID), passwords, and SNMP community strings. Disable SSID broadcasts. Enable WiFi protected access (WPA and WPA2) technology for encryption and authentication when WPA-capable.
[...]
9.1.3 Restrict physical access to wireless access points, gateways, and handheld devices.
[...]
11.4 Use network intrusion detection systems, host-based intrusion detection systems, and intrusion prevention systems to monitor all network traffic and alert personnel to suspected compromises. Keep all intrusion detection and prevention engines up-to-date.
[...]
12.3 Develop usage policies for critical employee-facing technologies (such as modems and wireless) to define proper use of these technologies for all employees and contractors. Ensure these usage
policies require the following:
12.3.1 Explicit management approval
12.3.2 Authentication for use of the technology
12.3.3 List of all such devices and personnel with access
12.3.4 Labeling of devices with owner, contact information, and purpose
12.3.5 Acceptable uses of the technologies
12.3.6 Acceptable network locations for the technologies
12.3.7 List of company-approved products
12.3.8 Automatic disconnect of modem sessions after a specific period of inactivity
12.3.9 Activation of modems for vendors only when needed by vendors, with immediate deactivation after use
12.3.10 When accessing cardholder data remotely via modem, prohibition of storage of cardholder data onto local hard drives, floppy disks, or other external media. Prohibition of cut-and-paste and print functions during remote access.

The above text was copied from the standard document and to fully grasp the implications involved I would, as I did above, recommend you to read Aegis PCI DSS Wireless Security FAQ.

Also, version 1.2 of PCI DSS is to be “released” in the beginning of October and you can find the document of changes here (PDF).

I’m sitting here preparing for a meeting at which I will discuss our role in a clients PCI DSS project, and I thought it might do others good if I post what I’m thinking also.

First off, remember that all of this is from a perspective of a Panda AdminSecure/MalwareRadar point of view and it might not apply for other solutions.

Alright then. Which control objective’s and sub-objectives are we even directly responsible for when helping the client achieve compliance? By my thinking it should be:

Requirement 5: Use and regularly update anti-virus software or programs (all subs)

Even though the term anti-virus doesn’t really apply anymore, we can help with this

Those that we might be affected by/can help with are:

Requirement 6: Develop and maintain secure systems and applications
— 6.1 Ensure that all system components and software have the latest vendor supplied security patches installed. [...continued]

Requirement 11: Regularly test security systems and processes
— 11.2 Run internal and external network vulnerability scans at least quarterly [...continued]
— 11.4 Use network intrusion detection systems, host-based intrusion detection systems, and intrusion prevention systems [...continued]
— 11.5 Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system or content files [...continued]

and how can we do that? My notes on all mentioned subcomponents below…

The main ones:

5.1: This point discusses deployment of anti-virus protections. With Panda solutions, there’s no problem here. Deployment can be done by pushing (RPC) or setting login scripts from within the console and there is also .exe’s and .msi’s available for those that have bigger deployment solutions.

5.1.1: This point discusses verifying correct operation in the solution at hand and seeing to it that it also detects and removes other threats such as spyware or adware. The function verification is really up to the client, but of course we’ll help ‘em if they need help heh… And spyware/adware has been a part of our signature since 2004.

5.2: This point discusses the monitoring of the chosen solution to ensure that it is working, it is updated and capable of generating logs. All of this can be monitored from within the AdminSecure console and scheduled reports can be set up to inform admins of the current status. There is also the possibility of using other logging and notification services such as syslog and snmp, but one should be aware that these units need to be reachable from the client computers as the warnings will originate from them.

and then the others that we might be able to help with:

6.1: This point discusses the need to ensure that all computers have all security related patches applied. We can help with this by offering scans with MalwareRadar (distributed by pushing (RPC), .exe’s or .msi’s) which does both low-level scanning with a huge (too huge for on-access scanners) signature and patch inventory on scanned machines. MalwareRadar is a part of AdminSecure as of version 4.02.01 (beginning of 2008 I think).

11.2: This point discusses running vulnerability scans periodically or after significant network changes. MalwareRadar might be applicable here, but I would not really classify it as a vulnerability scanner. From marketing they will however probably say that it applies

11.4: This point discusses and encourages the use of NIDS, NIPS, HIDS and HIPS. In this section we can help with the HIPS part via TruPrevent. Truprevent is more than just a HIPS but it has all feature’s of one. This component was released in late 2004 and has been optimized since for both capabilities and performance. Installs by default on both clients and servers. Read more here, here and here.

11.5: This point discusses the use of file integrity monitoring software. This is being done in part by our client protection with TruPrevent (see point above) on some critical system files and behaviours. It could however be locked down even further by customizing the ruleset. For a simple example, one may not modify the “hosts” file in certain ways. TruPrevent is not the answer to this point 100% though, as what they are really after is a checksum monitor like Tripwire.

Ok, that’s about it.

If anyone think I’m totally of target or if they have other ways of looking at this, please let me know!

From ComputerWeekly.com:

Reports say Geeks.com sent out a letter at the weekend to its customers, admitting that customer information, including names, addresses, telephone numbers, e-mail addresses, credit card numbers, expiration dates, and card verification numbers, may have fallen into the wrong hands.

As a comment in this article mentions, this incident once again highlights the issue of encrypting customer data. Not “only” to secure the customers creditcards but also to stay clear of lawsuits and other liability issues.

I think I read somewhere about this being a requirement for this kind of vendor/merchant:

3.2.2 Do not store the card-validation code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions

Well well, this is yet another wake up call for those that are not yet handling their data the correct (secure) way.

Cheers,

http://jeremiahgrossman.blogspot.com/2007/11/live-online-roundtable-episode-1.html

For me, the part of the talk dealing with WAF’s (web application firewalls) and normalization of input was quite interesting. As discussed, there really is no good way to do it if the customer or developer do not know they way his server and webapps handles input (and output for that matter) and which features are needed. However, if there is good documentation of the webapp that is to be protected, you might get away with some normalization (and then why not do it). WAF’s in general is not something you “just plug in” and some more fine tuning will most likely be needed if normalization is something that you want to do.

Another thing that i thought was actually more interesting, was hearing these people that are specialists on web security discuss the PCI DSS and what their experience and comments on it were.

One good thing with the PCI DSS is that for an CTO/Administrator/Security engineer that is really dedicated to providing good security for his company and it’s clients, the standard can be used to push up security budgets and raise awareness in upper-management. However, the money will also have to be well spent, and that’s where some of the participants see a problem.

That problem is that companys and departments with dedicated budgets will try to hold down costs, sometimes even if they have the money needed for a thorough security solution, all for increased profit. This in turn might lead them to cheaper and less reliable certified scanners and vulnerability testers, that might not find holes where there actually are plenty. What does this lead to? Well, not much for those trying to fill the PCI’s requirements, as they will still pass (AND with no problems detected, wohooo). The cost, as usual, ends up with the customer that gets his or hers creditcard-data stolen from the site.

An update on this were posted by RSnake (one of the participants) on the 11/11-07.

Another topic regarding the PCI DSS that was discussed was it’s unclarity in certain paragraphs that might lead to total or partial circumvention of the upholding of the standard. No comments regarding this but it does indeed sound pretty serious if that’s the case

More information on the PCI DSS here. And I also recommend you all to visit the link in the top of this post and listen to the whole webinar.

Cheers,