Cassandra Security

Analysis of the security industry, and all that it influences.

• Home
• About Us
• Events
• Research
• Papers
• Podcasts
• RSS

Today I read a blog entry which both amused and troubled me.  The entry in question can be found here and was written by Anton Chuvakin, a smart cat who is obviously trying to draw parallels where they simply do not exist.  In this case, he asserts that there are at least 9 reasons which describe how (and why), the PCI-DSS standard and Advanced Persistent Threats (APTs) are alike.   Not being new to either, I thought I would read Anton’s entry and see where he was going with this…apparently to la la land…..  Let’s take a look at what he asserts.

First and foremost, he asserts that they are similar.   I find that humorous at best and borderline irresponsible at worst.  PCI, as you dear reader, are well aware is a governance standard created by the payment card industry (the PCI in the PCI-DSS) in order to ensure a homeostatic baseline from which all vendors, merchants, and processors conducting business with the big 6 in payment cards exists and can be measured against.   It has nothing to do with threat modeling or mitigation nor does it ensure (as we are painfully aware of due to the unfortunate events which took place at Heartland, Hannaford and a host of others who were either certified PCI Compliant or in the process of being certified), that anything beyond the scope of those systems which comprise the environment which processes credit card information are secured (this is accomplished via vulnerability scanning, and auditing against the standard), leaving the remainder of the enterprise to sway in the wind like yesterday’s laundry. For the record, I don’t think PCI is good or bad, but rather like climbing the rope in gym class: if you want to make the grade, you’ll get up that rope otherwise you’ll receive the consequences.  It doesn’t really speak to one’s athletic capabilities or aptitude however it does impact your grade…PCI is more akin to this than APTs.

Anton asserts the following (whether in jest or in all seriousness is debatable):

• “P” in “APT” stands for “persistent”, “P”in PCI stands for … well … PCI is pretty darn persistent

1. Ok…this is cute but hardly relevant or helpful to any combating or faced with the prospects of combating and defending against the realities associated with APTs

• Both are absolutely a threat, whether of non-compliance or of severe 0wnage…

1. Both are not threats.  The penalities associated with the failure to comply with the PCI-DSS standard if one’s organization hopes to continue doing business processing credit card transactions is a promise whereas the threats associated with ‘APTs’ are wildcards and cannot be guaranteed as no two ‘APTs’ are alike.

• “Nobody would ever find that we lied on our SAQ” is said sometimes in PCI, and “no APT will want to hack us” is often said about APT.

1. I have no issue with only because it is generally true that in making assumptions which eliminate the possibility of risk one does oneself no favors

• People under PCI sometimes do not want to update their anti-malware defenses, because they say “it is too hard.” People under APT often also do not update their anti-malware because… hey… what’s the point?

1. In all my years in consulting, working in research, and for two different information security vendors I have never met an organization who said updating was too hard.   I have however met several who have asserted that the politics which governed their environments were prohibited and that their management teams were — for better or worse, comfortable with the assumed level of risk under which they labored and operated.  Fair enough, it’s your environment, do as thou wilt.   However, in working with those who have been victimized by ‘APTs’ I can tell you that none have ever (let me reiterate EVER) said what’s the point in updating their malware defenses.  The reality is that 99.999 % of the time, they were completely unaware that their environments were at risk, they were updating their defenses and assumed their vendors were maintaining congruency and continuity with respect to the content they were delivering.   In most of these cases, the advanced analytic tools which were necessary (above and beyond logging and monitoring by the way), were not present within these environments and as a result the ability to track the activity associated with these threats was absent.

1. “A” in APT stands for “advanced,” PCI is pretty advanced stuff for some people who have to be compliant with it (think: your neighborhood gas station)

• True however there are restrictions and guidelines associated with transaction levels (minimum activity and dollar amounts etc.).  ‘APTs’ are not always terribly advanced. Ghost Net is a phenomenal example of this.  The vulnerability which was exploited was quite old, the tool which was used was not sophisticated (Ghost RAT), and the rest is history.

1. With PCI, you don’t always know what you need to do; with APT you almost never know what to do.

• PCI is well documented and the domains clearly articulate what is required in order to meet compliance in terms of operational controls (manual & programmable), in addition to internal and externally related controls.  I already addressed the nature of ‘APTs’ two bullet points ago however will reiterate that by the time you are aware one is in your environment (provided you are not in possession of the types of technologies which would provide you view necessary to capture and identify associated ‘APT’ activity), it is too late.  At this point you’d need to take immediate steps to stop the bleeding (exfiltration of data) from your organization.

1. Also, you are never “done” with PCI, you need to maintain compliance and security; you’re absolutely never “done” with APT.

• Agreed but again this is true of all things within information security.

1. PCI compliance requires logging and monitoring; dealing with APT absolutely requires extensive logging and monitoring.

• PCI does require logging and monitoring.   However APTs require (as I mentioned previously), much more than simple logging and monitoring.   Session based analysis, for example, must be present if it is not you will likely never see an ‘APT’ coming, going or just hanging about collecting data.

1. People refuse to deal with PCI because they do not believe that anything bad will happen to them, similarly people refuse to deal with APT since they don’t know that APT has already happened to them.

• This is an oversimplification of the challenges associated with both PCI and ‘APT’s (and part of the reason I stated earlier that Anton’s orginal post was borderline irresponsible).  PCI has teeth unlike many other regulatory and / or compliance acts.   This is true for several reasons not the least of which is that it is not being pushed by the federal government but rather originates with privatized business thusly placing stringent conditions upon those who must meet its criteria in order to remain in business.  People do not refuse to address ‘APTs’.  This is both preposterous and asinine.   Most people, specifically those outside the financial services, defense industrial base, or research & development environments (pharmaceutical, high technology, low technology etc.), are unaware of the existence of ‘APTs’.  Being unaware of the existence of something does not in any way imply that under other circumstances one would refuse to acknowledge the existence of something should proof be brought forth.  This is an under developed line of logic and it is logic such as this which is being espoused within the industry today that is allowing for ‘APTs’ to become the hot topic amongst any and all vendors who may or may not have any experience or expertise with these threats

I hope this comparison and contrast was helpful to those who read it as well as Anton’s blog. My goal in writing this is three fold:

1. To ensure that the dialogue pertaining to APTs and other advanced families of threats remains pure and unadulterated.
2. To ensure that inaccuracies and under developed concepts are prevented from permeating the cultural zeitgeist.
3. To ensure certain parties avoid liberating graphics from entries posted here at Cassandra Security

Comments

• Categories

  • Advanced Persistent Threats (APT)
  • Assessment
  • Audit
  • Backdoors
  • Bot Nets
  • Cloud Computing
  • compliance
  • Crime and Punishment
  • critical infrastructure
  • Cyber Crime
  • Cyber Defense
  • Cyber Fraud
  • Cyber Terrorism
  • Cyber Warfare
  • Information Security Philosophy
  • Malicious Code
  • Malicious Content
  • Next Generation Threats
  • Patterns & Profiles and Threat Vectors
  • PCI-DSS
  • Risk
  • risk management
  • Rootkits
  • SaaS
  • Security Philosophy
  • Subversive Multi-Vector Threats (SMTs)
  • Terrorism
  • threat
  • Threat Modeling
  • Trojans
  • Uncategorized
  • Vulnerabilities & Threat Research
  • Whitehat
  • Whitepapers

• Archives

  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009

• Blogroll

  • Arbor Networks Blog
  • CSI Provoked
  • Dancho Danchev
  • Fudsec - Showcasing Fear, Uncertainty and Doubt from the Information Security Industry
  • Gunter Ollmann's Blog
  • Harlan Carvey's Windows IR Blog
  • IANS Perspective
  • Joanna Rutkowska of Invisible Things Labs
  • Nelson Brito (no português)
  • Our Twitter
  • Palantir - Palantir Technologies
  • SANS Internet Storm Center
  • Schneier on Security
  • Security Fix
  • Security Incite
  • TaoSecurity
  • The Art of Software Assessment - Mark Dowd, John McDonald, Justin Schuh
  • The Threat Post - Kaspersky Lab Services
  • the451group

• Admin

  • Register
  • Log in
  • WordPress
  • XHTML