Archive for September, 2010

Quick Thought: Monitoring Data Exfiltration to the Cloud

September 10th, 2010 1 comment

Truth be told, this thought was sparked by my friend Rob Rounsavall at Terremark while we were presenting at the SANS Virtualization and Cloud Computing Security Summit in DC last month.

The question is simple – with the concerns we have surrounding cloud security, whether providers meet our basic policies and practices, let alone compliance requirements, can we allow business unit IT teams, developers, and others to use “pay with a credit card and get started now” types of cloud services? The answer is likely no…but this is much like telling people they shouldn’t speed in their cars. Without some enforcement mechanism, they’ll do it. So if we’re concerned about this, just creating a “policy” may not help us, especially in large, distributed organizations.

So what kinds of outbound detection/blocking are folks doing (if anything)?

1. Snort or other IDS rules for sites or specific content elements associated with these cloud services? Something like:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg: “Cloud Madness!”; uricontent: “\xyz”; flow: to_server, established; classtype: cloud_is_bad; sid: 31337; rev:1;)

Yes, I know this is more of a “pseudo” rule. Just a thought.

2. More traditional content filtering like Websense?

3. Proxy or DLP filtering?

Rob asked the crowd if they were doing this, and no one really had much to say, so I’m assuming it’s not something many are thinking of…yet.

Categories: Information Security Tags:

The 13th Requirement

September 1st, 2010 Comments off

Now, at long last and after much personal expense and toil, I am proud to bring to you the fabled 13th Requirement of PCI DSS. Long rumored to exist, I recently managed to wrest these from the dank basement stronghold of a Masonic Lodge in Milwaukee, while dodging capture by their roaming guard of free-range chickens (those things are DANGEROUS!).

Just as you would expect, this is essentially the Rosetta Stone of PCI. All the confusion, all the gray areas that weren’t clear, all the ambiguous references to technology and technical specifications – cleared up with one section that the Council did not want you to ever see. So, without fail, I give you – Requirement 13.

Requirement 13: It’s somebody else’s problem.

13.1 PCI Merchants and Service Providers, under no circumstances, should take responsibility for sound information security practices and satisfactory compliance status.

13.1.1 PCI Compliance is the QSA’s problem. Never admit that you’re doing anything wrong, or that your practices are not sound.

13.1.2 If a passing ROC cannot be obtained from your QSA, attempt to discredit him/her and their organization.

13.1.3 If a passing ROC is obtained, but is completely bogus (see section 13.2.2, “Rubber Stamping”), and an incident/compromise occurs, attempt to discredit him/her and their organization.

13.2 Qualified Security Assessors will claim to be objective, but in actuality will be subjective based on prior knowledge, perception of customer, and QSA consulting firm contracts and business needs.

13.2.1 PCI Compliance is the customer’s problem. Never imply that anyone but the customer is directly and wholly responsible for all facets of PCI compliance, regardless of whether the QSA has a clue about the technology, business processes, or CHD flow.

13.2.2 As long as sufficient “evidence” of controls can be provided, keeping the customer happy and paying the bills should be the QSA’s primary concern. This is often referred to as “rubber stamping,” and is often encountered when merchants and service providers prioritize compliance over actual security measures that meet best practices.

13.2.3 Neither the PCI Council nor the payment card brands will offer the slightest assistance throughout the course of the PCI assessment. Verbal “blame shifting” is acceptable when clients demand specific answers.

13.2.4 In the case that a client is compromised, or experiences a breach of CHD, a QSA must never admit fault. Disavow all knowledge of the technical or procedural shortcomings that may have led to the breach, and strongly insinuate that the client may have been “hiding” things during the assessment.

Well. Hope this clears things up. 🙂

Categories: Humor Tags: