Three Questions to Avoid Suffering in Security

Take a look at this article I just wrote for ebizQ

Avoid Security Suffering With These 3 Questions
By Jack Danahy, Founder and CTO, Ounce Labs

As an active speaker at industry conferences and events, participants often come up to me and ask where is the right place to start implementing security.

Among those looking for the answer are new CSOs overwhelmed by the prospect of overhauling an organization's security infrastructure and business people thinking of how to cost-effectively improve security. What they all have in common is the search for a simple answer to a complex issue, and they are all asking the wrong question.

Read the rest of the article here

In Search of: New Scary Metaphors

I had the good fortune of speaking on a panel at the Symantec Government Symposium on Tuesday of last week, and just previous to my own slot I was listening to Melissa Hathaway describe the work that has been done on the President's 60 day evaluation of national cybersecurity. I know that much has already been written on the subject ( the document is here ), so I won't belabor that topic.

I think it is worth mentioning one of the painfully overused metaphors that came from the audience, because it is so common, and so frequent, that it has become, for me, like the incessant sound of my GPS when it disagrees with my choices, ("Please return to the highlighted route") over and over and over and ... Sorry, I digress.

The audience member was asking about the steps that the government and the private/public partnership were to take, and whether Ms. Hathaway thought that these measures would enable us to avoid ( wait for it...wait for it ) the

Cyber Pearl Harbor

...Ugh...

This unfortunate turn of phrase is often, and evidently inaccurately, attributed to Mr. Richard Clarke. It is most often used to conjure up the vision of a cyber attack which can be mounted at a monumental scale, can be executed with incapacitating speed, and can be accomplished with near total secrecy. It made sense, when we first started thinking about cyber security in this more holistic manner back in the mid-1990's, as a hook to get people emotionally involved in the threats that so many of us could see lurking in our oncoming Internetwork-ed future. In time, though, the cyber sneak attack became weak tea, as the new generation of physical sneak attack rocked us on 9/11. Recently, though, through periods of foreign conflict and economic crisis, we are getting more more insight into possible venues for incursion and into likely footprints left by cyber scouts, and now we have begun to hear the chant again.

Cyber Pearl Harbor

...Ugh...

So what is so bad about describing a potentially widespread cyber attack as a "Cyber Pearl Harbor"? What would cause me to sit here and write about a turn of phrase that has become as common as "irregardless" and "I could care less"? For starters it is confusing, and for finishers it communicates little to the listener. It misrepresents the nature of the threat, the likely damages and the probable agents, and worst: the role that so many should play in reducing the probability of an attack's success. Here is what I mean:

Pearl Harbor versus Cyber Attack : The nature of the threat

The attack on Pearl Harbor was a surprise attack on the US Naval Base at Pearl Harbor Hawaii in 1941. Over 350 Japanese aircraft destroyed 11 vessels and killed over 2,400 US personnel, pulling the US of the time out of its isolationist position and into World War II. A day that will live in infamy. But it is important to understand that Pearl Harbor, while a surprise, was a largely isolated event, both physically and politically. Hawaii is roughly 2,000 miles from the mainland US, and in 1941, it was still almost 20 years from becoming the 50th state in the Union. So the attack and the threat were largely limited to that area, and to the US Navy in the region, and the attack's role in catalyzing public opinion to go to war reflected an acknowledgement that such an act could likely lead to others more directly threatening to the country as a whole.

This reality, and the concern about future incursions, are in marked contrast with the object and results of a likely cyber attack. The nature of internetworking, and one of its design objectives, is the geographic insensitivity of its hosts. A well-formed attack would be unlikely to be limited to one region, could more easily be expected to focus on one industry (energy, finance, government, telecommunications), or on the privacy, availability, and integrity of all information that is commonly passed between various constituents on the network. The threat is very different because while it is possible that there would be physical events and damage resulting, it is more likely that the effects would be pervasive among many or most citizens, and that they could be very long lasting and irrecoverable. This leads us to the next disconnect in the Pearl Harbor vs. Cybertastrophe debate, the likely damages and probable agents.

Pearl Harbor versus Cyber Attack : Damages and Damagers

There is no question that the loss of life and strategic resources in the Pearl Harbor attack made it a very successful initial gambit on the part of 1940's Japan. At the same time, and in conjunction with Japan's signing of the XXX support treaty with the Axis countries of Germany and Italy, it pulled the otherwise sidelined US into the World War II conflict. Japan, while a fortified and well-trained island nation, was located in the same place that it had been for hundreds of years. It was a country, with a government, and a military, and boundaries, buildings, and citizens. Its attack on Pearl Harbor invited retaliation, and that retaliation would be focused on its homeland, its people, and its infrastructure. The damages from Pearl Harbor were very visible and very real, but so were the flags and followers of Japan.

The damage from a cyber attack is unlikely to be so easy to bound, visualize, and measure, and if done well, the attackers can cloak themselves in high-grade anonymity unbreakable by today's technologies. The attacks themselves can be in real time, scheduled, or triggered. They can be executed from local, remote, stolen, hijacked, or simply innocent systems. Their countries of origin can be anywhere, including on our own shores, and many styles can be executed by automatons, running mindlessly in background processes as they wait for the signal to launch.

The actual damage itself can be much more insidious than straightforward destruction. Minor corruptions and losses can lead to a deterioration of confidence in financial, governmental, and medical services. Alterations can be subtle enough to escape normal scrutiny, but can act in concert to create massive disruption. Our nation's accelerated adoption of all things technical has made us flexible, advanced, and productive, but it has also left us most vulnerable to attacks which would co-opt those same technical elements. Which leads us to the worst effect of considering Cyber threat as Pearl Harbor threat; a lack of involvement and interest from citizens and industry in fundamentally improving security and managing cyber risk.

Pearl Harbor versus Cyber Attack : Who Lets the Enemy In?

Whether Pearl Harbor or the tragedy of 9/11, our national response has been largely the same: "How can We have let this happen?", where We means the government and not the actual We, the People, and this means major damages that take us by surprise. It is, in the case of these physical attacks, natural to look outside of ourselves for protection. Most of us do not own the destroyers and aircraft carriers that carrier our sailors and marines to war, and we are definitely discouraged from stocking up on the type of anti-aircraft weaponry that would have made us marginally useful in defending Pearl Harbor. That is the job of Government.

This is where Cyber Security, and protection from much of the Cyber threat, takes a sharp left turn from discussions of Pearl Harbor. We (the private citizen, corporate executive, IT professional, We) must be part of defending against cyber attack. Explosions of bots on unpatched machines, pathetically weak passwords and wide open services, software written without sufficient care for security or privacy or integrity, these are all areas where people, not Government, must step up. We cannot expect all citizens to be security experts, but we need to take the time to acknowledge and then empower a basic water level raising for all, so that we do not leave ourselves so obviously and easily exposed. The measures are not that difficult, but they are purely impossible to mandate from on high, we must accommodate them ourselves.

Blah Blah Blah, So What?

Many of you, while familiar with my frequent riffs on odd topics, might think that this is a lot of writing to blow on a random audience guy's question, but I don't think it is. Our perceptions of reality are driven almost entirely, by our experiences and our history. We are all familiar with Pearl Harbor, or 9/11, at least in their broadest brush strokes. When we accept the Pearl Harbor metaphor, or perpetuate the thinking that cyber attacks will look like that, we shape our thinking to view protection as protection against an event. We view our defenses as defenses against an enemy. These assumptions, and the mitigation that they will engender, are just wrong.

If an attack comes, it will seep into our system like a slow acting poison, and we will not recognize it, or know to act against it, until we are already deep within the control of it. If an attack comes, we will not find ourselves face to face with an attacker ready to do battle, but with a dark and gauzy space where we can only strike at shadows and hope by luck to hit something. Protection against these threats will come only with awareness and responsibility, and a sense among all of us, that we are responsible for our own protection. If each of us, as individuals, and businesses, and technologists, take this role seriously, then the odds of our success are enormous, because our enemy in this case is much more like a virus or an illness than a country, and our best and only hope is to inoculate ourselves.

Commentary on FERC Position Paper

I have had a couple of masochistic requests for the actual content of my commentary on the FERC position paper I mentioned in my last post. It will not necessarily be my most riveting blog content, but I am here to please.

I would also genuinely appreciate any feedback from you, the readers, on what you think of both the general document and my views on these few areas.

Comment 1: Docket No. PL09-4-000, Page 4, Subsection 4

4. We seek comments from the industry on these and other steps the Commission can take to encourage and expedite the development of interoperability standards and implementation of Smart Grid projects. In the near future, we may convene a technical conference for further public input on these issues.

The document is quite clear on the use of rate-based incentives to assist in motivating organizations to invest in the development of the Smart Grid infrastructure. These are an excellent catalyst for organizations that will be involved in the generation and distribution of power, but are unlikely to directly impact the efforts of the ancillary organizations from whom much of the components, software, infrastructure, and ideas, are likely to flow. Similar to the outright grants that are available for development in the alternative energy, health care, and urban development areas, federally managed funds could be made available for organizations to either commence or accelerate the advancement of integrating technologies, particularly in areas that are unlikely to attract the interest of the traditional power partners in the Grid. It is probable that educational institutions, infrastructure providers in other markets, and a host of small businesses, could apply an exponentially larger group of resources to some of the most difficult problems, with sufficient funding and well-defined goals and results.

Comment 2: Docket No. PL09-4-000, Page 11, Subsection 14

In the section described as “Cybersecurity and Reliability”, the reference is made back to the EISA and FPA standards, both of which focus attention on disruption as a defining feature of a cybersecurity incident. From the FPA Section 215:

The term `cybersecurity incident' means a malicious act or suspicious event that disrupts, or was an attempt to disrupt, the operation of those programmable electronic devices and communication networks including hardware, software and data that are essential to the reliable operation of the bulk power system.

We know from commercial experience and from recent disclosures regarding incursions into the existing Grid that cybersecurity incidents are often not immediately disruptive. Data theft can provide deep intelligence into Grid logistics and operation, and passive malicious code is frequently left behind for use later as either a hidden inroad or a data egress mechanism. The proposal should be more specific in its own language, and should characterize any unauthorized access to, or modification of, a critical system as a “cybersecurity incident”. Failed attempts in this regard should also be identified, as they can often provide a predictive pattern of behavior in the even of a future incursion. Power disruption may well be the ultimate goal of some of these attacks, but the less obvious damage caused by information leakage and system compromise lay the groundwork for either a more damaging, or more widespread, event in the future.

Comment 3: Docket No. PL09-4-000, Page 22-23 Subsection 29-31

Within these sections, entitled “System Security”, there are references to the existing North American Electric Reliability Commission Critical Infrastructure Protection Reliability
Standards, as well as references to ongoing standards work by NIST, the AMISEC working group, and others. While each of these organizations will be generating valuable input to the definition of system security for their various purposes and disciplines, the Smart Grid will require a more holistic view which encompasses those requirements, but tailors them to the evolving risks and capabilities of the grid.


There should exist within this proposed plan a program to generate a dynamic system security office, one which is capable of consuming the advancing state of the art from the various Smart Grid constituencies, in conjunction with an understanding of the advancing threat models that could put the Smart Grid at risk. It is doubtless that these various standards will, themselves, evolve over time, and it should be accepted that the digestion and deployment of these standards will be an iterative process managed by a group responsible for the overarching balance of security and power provision. Similarly, there exists within the security discipline the concept of composability, which relates to the construction of complex systems from individual elements or components. The reality of these assembled systems is that an amalgam of highly secured components will often demonstrate itself to be insecure in the whole, as there are areas, cracks, in the actual integration of the parts. Few currently scoped projects will be likely to have more individual elements than the currently conceived Smart Grid, and composability will undoubtedly result in serious weaknesses unless the assembly is overseen by an organization with a comprehensive view and authority for securing those systems.

Comment 4: Docket No. PL09-4-000, Page 26-27 Subsection 35-36

These sections are described as “Situational Awareness” and are centered on creating a secured means aggregating and synthesizing data around the behavior of the grid. Concentrating on the requirements of reliable and accurate data flow to facilitate load-planning and balancing, the section describes the need for cybersecurity as an enabler and assurance of that data quality.


It is likely that any anomaly, disruption. or cybersecurity event/incident on any component of the Smart Grid should also be treated as a potential element in a more pervasive security or reliability problem across the Smart Grid. An intermittent component failure may appear innocuous in the context of a single network or microgrid, but a recurrence of similar failure across multiple infrastructures could provide early warning of quality or cybersecurity concerns within that component.


As a result, Subsections 35 and 36 should also mandate a capability of presenting either raw, aggregated, or filtered data into other data analysis platforms for generating situational insight across regions or grid components, in order to present the most informative picture possible. As the information is already being gathered in this current proposal, it will only require a simple addition to provide an open set of secured interfaces through which that data can be accessed.

Foreseeing Federal Policy for Smart Grid Security

For those of you who are security devotees and are looking for a new place to offer some value, and for those of you who are dedicated to the Smart Grid and are worried about security, I'd like to draw your attention to the draft Federal Energy Regulatory Commission's (FERC) Smart Grid Policy Paper issued in March, and closing on comments this coming Monday, May 11th. Admittedly it might be a bit close to the wire for those of you looking to add your own views to the process, but as this is really only a draft, I figured that both communities would do well to be aware of what is coming in this potential policy so that you will be better prepared to think and act on it.

As this is a fairly standard ( read: complicated ) paper, I've broken out the pieces that struck me as interesting or troubling, and have tried to create a sort of CliffsNotes version for your examination. First off, let's pull out the purpose of the policy statement, directly from the document itself:

"The purpose of the policy statement the Commission ultimately adopts will be to prioritize the development of key interoperability standards, provide guidance to the electric industry regarding the need for full cybersecurity for Smart Grid projects, and provide an interim rate policy under which jurisdictional public utilities may seek to recover the costs of Smart Grid deployments before relevant standards are adopted through a commission rulemaking."

I like this. Think about the parallel to the Internet. If, prior to the goldrush deployment boom in the mid-late nineties, someone had stepped up and said:

"The purpose of the policies will be to develop and prioritize standards for secure internetworking, providing guidance to telecommunications and content providers on the full range of internetworking services and protocols, and provide a cost recovery plan for those providers so as to incent the development and deployment of a secure infrastructure prior to widespread adoption and exposure."

I think we would today be facing a much more manageable universe of problems, which, while potentially resulting in many of us seeking other forms of work, would have certainly saved time, pain, and money. So I am in support of the stated purpose of the FERC's effort in this paper.

Beyond the purpose of the document, there are several positions that are taken/proposed, so I will pull those out here to cut to the chase. Recognize that there is a fair amount of justification detail within the document, as well as further clarification, and that these are my translations/distillations of those items.

Proposal 1: Rate stability and recovery

I am very much in favor of the beta-carotene-rich nature of the motivators described repeatedly in the document. It consistently calls for various positive security behaviors to be rewarded with "...timely rate recovery and other rate treatments..." There is also a realistic perspective on the likely unsettled nature of cost recovery and rate setting during the implementation and adoption of the Smart Grid over multiple years, and that is reflected in a proposal for a corresponding rate policy to level it out.

An area that is particularly ripe for response is a request for suggestions that will encourage the development of interoperable standards and to accelerate Smart Grid adoption. From my vantage point, an insecure Smart Grid is going to become more problematic than profitable. As a result, I believe that a straightforward means of catalyzing the various groups to make rapid progress on standards is to position them as the litmus test for eligibility to participate in the new grid. The organizations who are most likely to possess the expertise and resources necessary to adequately define those standards are also the organizations who are looking to engage in and profit from it. By restricting the progress of wide-spread deployment until such a time as these organizations can jointly develop and approve the standards, natural market incentive and pressures will cause enlightened self-interest to accelerate and rationalize the typically protracted standards negotiation process

Proposal 2: Standards, Standards, Standards

There already exist multiple standards that regulate security practices in the electrical system. Notably the Energy Independence and Security Act and Section 215 of the Federal Power Act are frequently provided as reference documents. In addition, the expected market for Smart Grid enablers will bring hundreds or thousands of new components and players into the mix. As a result, while standards are a nightmare to arrive at, it is absolutely critical to ensure this consistency, and given the highly interconnected DNA of electrical power, ignoring the likely collision and confusion of differing standards would reduce or eliminate the possibility of a manageable and secure sum-total power system.

In various parts of the document NIST and other groups are identified as likely and appropriate owners of the reconciliation, management, and ongoing enforcement of these standards, and I believe that to be the right move as well. When looking at the "standards ecosystem" it seems to me that the "Pushme-Pullyou" of agreement incentive and implementation enforcement seem pretty well-balanced, at least in their sketchy draft form.

Proposal 3: Be conscientious on traditional security as well

Given the interactive nature of the Smart Grid, there are also traditional security constants that have to be considered and managed. The integrity of the data, the appropriateness of authentication and access control, and the physical security of any Smart Grid devices. The paper suggests that the starting point be the North American Electric Reliability Corporation's Critical Infrastructure Protection Reliability Standards, with additions. These additions are clearly necessary, given the recent disclosures(and longheld fears) about the vulnerability and corruptibility of the existing legacy grid.

That said, this type of document and these types of protections tend to be much more dynamic than the creation and implementation of protocols and other embedded mechanisms. The threat changes, and I believe that this section will be best defined as a program, a necessary work-in-progress. While the institution of some current baseline of protection is clearly necessary, the proposal should also endeavor to describe the ongoing nature of the re-examination of the threat surface, in order to maintain close-to-parity with the organizations and individuals that might attempt to disrupt the Smart Grid.

This is only a brief synopsis, though perhaps an overly long blog post, on the potential new directives for securing the Smart Grid. I would again recommend that if you have taken the time to read this missive that you also take the time to read the actual paper.

I think that the challenges described in the position paper are manageable, but are massive. Addressing them requires that competitors agree on standards, that legacy systems be treated like full citizens in a new grid environment, and that we must temper our impatience for the Smart Grid with the knowledge that it has to be secure to be successful. Electric power is not the discretionary utility that the Internet has been. We cannot wait for it to sort itself out, and we cannot invest in a system whose undirected diversity or insecurity will marginalize it almost immediately. If you are experienced in energy, please take an interest in understanding this new kind of security, and if you are experienced in security, please take the time to think about applying that experience to energy.

Medicating with Security

Welcome back to the blog. It has been a very busy April, punctuated by the annual pilgrimage to the RSA show, which has certainly grown far from the early days with an excitable Jim Bidzos railing about federal encryption export policy.

For those of you who could not attend, RSA is becoming more and more like an annual high school reunion. It is the place where you figure out where your colleagues have landed, where you sense whether acquisitions are working out, and where you can hear and speak about security with people who are often times as passionate, as enthusiastic, as frustrated, or as fatalistic, as you may find yourself.

I was speaking and listening at the America's Growth Capital show which does a Monday lead-in to RSA, and was struck by a question by 451's Nick Selby to a panel of security folks. He asked them for the way in which they positioned, or their customers understood, ROI for their products. At first blush, this is a question that we in the product/vendor role have heard or initiated countless times, and so it shouldn't have been such a big deal for me. I think though that it was its very familiarity, its omnipresent nature in so many of my interviews and presentations and customer visits, that caused me to suddenly think:

"ROI on security. Now that is a bizarre notion."

When I think about ROI, I think about "R", or "Return". Return means that for N dollars that I invest, I am expecting some amount of N back, and in traditional investments, I am expecting to get more than my initial capital. We all use ROI all the time to make decisions of where and how to spend our money, both personally and professionally. The reason why ROI fell apart for me, this year, after so many in the space, was that investing (the I) feels, sounds, is, so voluntary.

"I don't think I'll be investing in pork bellies, Winthorpe, the Return is just too paltry."
"I do believe that I will put my cash into Frozen Concentrated Orange Juice, Billy Ray. Quite an opportune frost this year."

All very voluntary, picking among the options, deciding where to lay a bet, or, in tough times, when to leave the money in the mattress. Security doesn't feel that optional to me.

I decided to circle the RSA exhibit floor on a quest to hear the variety of answers I would get from the booth-manning legions to Nick's query: "How do you or your customers describe the ROI from your solution?". I wanted to see if any of them made clear and credible sense. I was about 10 vertigo-inducing business concept contortions into this little project, disabused of any notion that people would have either perpetrated some alchemy of security spend into profits or would simply rebuff the premise of the question, when I ran into Intel's Steve Orrin, a long-time contact and colleague. I told Steve of my quest, and we ended up talking about the way that organizations approach security spending like people approach taking vitamins. "I should spend some money on this because people tell me it will make me feel better." After discussing and digesting this, I abandoned my ROI quest, because it was clear to me that we have a problem of a basic misapprehension. Security is not about vitamins, it is about medicine, and we are lacking the fundamental prescription.

When we talk about security, we most often are actually talking about insecurity: "Where am I vulnerable?", "Who can get into my systems?", "How am I detecting attacks?", "How do I keep the bad guys out?". We are only very rarely asking questions about our networks, systems, or applications, and how we will be improving them to stay ahead of potential issues, because we instinctively feel that we are already behind.

And that is true because, to torture the metaphor, most organizations are already sick. More advanced firms will have reduced the potential sources of their symptoms, novices will just not feel well, and some firms will just think they are always supposed to feel like this. Like a patient, who just feels too ill, or is visibly diminished, or who is told by a qualified physician that there is something wrong, there is no longer interest in the Flinstones Chewable, it is time for a prescription.

In security we are beginning to see this happen. When various industries reached the epiphany that they were in trouble from a security perspective, you began to see the rise of more prescriptive recommendations. You can look at the OWASP Top Ten, the BITS efforts in IT security, Basel II credit worthiness requirements, section 404 of Sarbanes, privacy standards in HIPAA, or most pointedly, the PCI DSS V1.N. These provided, to greater or lesser extents, some definite actions that organizations could take that would help to make them better. Noone asks, "What is the ROI of protecting customer data?", or "What is the ROI of complying with Federal mandates?", because they are not optional, they are necessary, and the "R" is solvency and viability as a firm.

Unfortunately, security remains a discipline that is shrouded in complexity, fear-mongering and quackery. Our industry is still at the stage of development where the underlying needs are not described in common terms, but rather there is constant rehashing of the symptoms of the problems, and these become the objects of discussion and treatment. As a result, there is far too much time spent thinking about what technique or technology can address a symptom, instead of being spent on understanding the business goal, required protections, and the most effective ways to implement, deploy, and manage them.

In my conversations with customers, partners, and the press, there is little argument that most, if not all, organizations are burdened with some meaningful type of insecurity and threat. It is important for us all to take responsibility for that knowledge, and to begin to treat our security improvement differently. I would propose the following habit change and litmus test:

1. Before I talk to vendors, have I specifically defined my problem?


2. When I think about my problem, am I addressing the cause of the problem or am I only focused on the threats to my security?


3. Have I thought about the simplest ways to fix the problem, including less technical moves like moving data, removing connectivity, and limiting access?


4. As I engage with vendors, do I have a list of the functions that I need, including deployment capability and flexibility, prioritized and communicated?


5. When I make the selection, am I investing only in the necessary protection to keep my organization safe?


6. When I envision the organization post-purchase, how do I feel about its security?

At the end of the day, ROI is a horrible metric for most security investments of people or products. This is because it is very rare for security to drive profits, and because it is so common for bad security to reduce profits. As a result, any security investment should be limited to that which must be done to remain secure, and should be reassessed frequently to ensure that it is still sufficient. More spending than that on security or security technologies will be wasted, never showing the kind of return that product, process, or promotional investments will. This prescriptive approach will create the most effective and balanced mix of investment and security, and will enable evolution and advancement over time.

Why does the PCI DSS get the blame for bad security?

There have been repeated commentaries in the trade press, at seminars, and even in the halls of Congress, that organizations are not secure just because they have been judged to be PCI compliant. Whether it is Heartland Payment Systems, Hannaford Foods, or any of multiple companies whose names don’t start with the letter “H”, we have seen a pronounced and embarassing disconnect between PCI compliance and an adequately secured environment.

Comments have looked like this:

From Warwick Ashford at Computer Weekly:
“The data breach at Heartland Payment Systems that exposed millions of credit card holders in the US to fraud, proves regulatory compliance alone is not enough. Despite being compliant with the Payment Card Industry Data Security Standard (PCI DSS), cybercriminals were able to gain access to Heartland's systems.”

From the venerable halls of Congress, Representative Yvette D. Clarke (NY) offers the following:
“I do not believe the PCI Standards are worthless; in the absence of other requirements, they do serve some purpose. But I do want to dispel the myth once and for all that PCI compliance is enough to keep a company secure. It is not, and the credit card companies acknowledge that.”

And this, from Dave Hogan, SVP/CIO of the National Retail Federation:
"The PCI guidelines are onerous, confusing, and are constantly changing."

All of these are pretty strong negative statements about PCI, at least in theory. In one light, though, they look more like misdirections, either delivered intentionally or out of a mistaken apprehension about what the PCI DSS is supposed to do.

When one actually reads the DSS, it says that it is “a set of comprehensive requirements for enhancing payment account data security.” It includes consideration of a variety of data security concerns, like secure networking, data protection, vulnerability management, access control, monitoring, and testing. It does not include any guidance for the multitude of ancillary and orthogonal systems that many organizations will also have on shared infrastructures.

This is because the PCI DSS was never intended to provide a holistic and sufficient set of organizational security requirements. It was intended to make cardholder data more secure. Unless your company name is WeJustHoldCardholderData.com, PCI CANNOT describe your security strategy, only a small component of it.

I think that the PCI DSS can be unpleasant for people, particularly for some retailers, because it is prescriptive. Like any medicine, it can be difficult to swallow, and it represents a change from the existing status quo. It doesn't matter what the prescription was, there was going to be some pretty strong reaction to it because it forces action, unlike many previous, less prescriptive, approaches. Look at GLBA, HIPAA, Sarbanes-Oxley, or Basel II. They are all good and important standards, but all are extremely light when it comes to detail and enforceability. They all rely on reasonable care from their adherents, and as we all know, "reasonable" is a wonderful lubricant to slide down the slippery slope to doing much too little.

In response to its many critics, particularly those claiming that PCI is too much work, or is of too little value, I would like to ask for an answer to a very straightforward question:

   What elements of PCI DSS do you think are unnecessary?

Good luck with that one.

It is common, when a group is against the fundamental purpose of a rule, or a law, or an agreement, to position their opposition to it as opposition to its effectiveness or its utility, or as an expression of distrust of the originators' motivation, ignoring the actual purpose and benefits. I can't imagine that anyone will, in good conscience, say that knowing where your data is going, and knowing how people access it, are not important. They are mostly resisting the need to comply or be fined, and that is where this discussion should go, because the effort to comply with PCI has value.

Here are four simple roles that PCI is currently playing:

Catalyst

PCI DSS and the aggressive enforcement of its mandates have brought awareness and education to many who would otherwise have marginally and incrementally improved their protection

Model

While the PCI DSS itself is focused on account data privacy and security, the model which it employs for data and transaction characterization and categorization are useful across any dataset

Process

The combined instruction and enforcement present within the PCI DSS can be applied cleanly to other areas of risk, including outsourced contracting, internal development and risk management/reporting

Validator

As has been cited numerous times by PCI DSS supporters and detractors, PCI auditing is a snapshot, while PCI compliance is actually a consistent measure over time, ideally validating a wide range of data security and privacy issues in a new and important way.

These all strike me as being well worth the effort that PCI requires, particularly because the benefits of their implementation should raise the water-level of security more broadly.

As a last item to add to this entry, here is some survey data that my company, Ounce Labs, developed from surveying several hundred security execs over the last couple of years:

If you are interested in a fuller discussion on this topic, take a look at my recent keynote, "The Role of PCI in a Security Strategy". You can likely take advantage of some of the slideware and the commentary as you consider and approach PCI and security together.

This discussion, the information around these breaches, and the general press coverage that is bringing the issues of data privacy and identity theft home to the public, are in part a reaction to the new rigor that PCI requires. I think it would be hard to say that we all would have been better off without it.

I am Feeling CERTIFIABLE

I admit that when I wrote my blog regarding what was, at the time, proposed cybersecurity legislation, I focused on the same areas that the mainstream press did. In the Cybersecurity Act of 2009, there was Presidential Plug Pulling, a new Advisory bureaucracy, funding for more security education in colleges, a call for standards, etc. But wait! There was more, and I really just breezed over it, until I stopped to think about it in practical terms, and I realized that the terms were not very practical. Within the legislation, there is Certification and Mandatory Licensing.

(a) IN GENERAL- Within 1 year after the date of enactment of this Act, the Secretary of Commerce shall develop or coordinate and integrate a national licensing, certification, and periodic recertification program for cybersecurity professionals.

(b) MANDATORY LICENSING- Beginning 3 years after the date of enactment of this Act, it shall be unlawful for any individual to engage in business in the United States, or to be employed in the United States, as a provider of cybersecurity services to any Federal agency or an information system or network designated by the President, or the President’s designee, as a critical infrastructure information system or network, who is not licensed and certified under the program.

This has got to be among the worst cybersecurity ideas I have ever heard of, somewhere between "Security by Obscurity" and "Just Trust the contractor to do the right thing."

This blithe call for licensing and certification in Senate Bill 773 speaks the language of the "Butter and Bombs", mainstream crowd, to whom the Senators are looking to communicate their sense for better security. It is a population that is unfamiliar with the deeply nested complexity and variety of issues that conspire to weaken cyber security. In speaking with some non-IT acquaintances about my discomfort, I could see the political logic for this language. "I need to get a license to drive, and that has got to easier than this." "A plumber or electrician needs to be licensed, why shouldn't a security guy?" It sounds great, in the abstract, to be able to give the imprimatur to trained professionals, weeding out the posers, but the nature of security, and of IT, makes this a massive misperception.

Security is not a monolithic expertise. Most "security experts" tend to gravitate to a specific area of security, whether it is crypto, or penetration testing, application analysis, or architectures. There is PKI, anomaly detection, intrusion prevention, and more. I could probably whip together an excellent Dr. Seuss story about all of the different types of security, but that would further distract me from the point. Security has many disciplines, and it is impossible to find anyone who would be good enough at all of them to be certified as an expert generalist.

This means that the likely outcome of passage of this legislation would be both more complexity and cost, with less expertise and far less available resources. The realization would come quickly that there needed to be classes of certification, and various types of licenses or credentials. "Jack holds his MCSA (Masters Certification in Software Analysis), his MCSB (Masters Certification in Security Basics), his MCSC (Multi-user Computing Security Certification), his MCSD (Mandatory Cryptography Standards for Data), and on, and on, and on." It would then fall to the customer/acquirer to decide what they needed. If they were well-informed enough to do this, they would already be hiring people with the right expertise.

It is also hard to imagine that the licensing process would be limited to expertise. It strikes me that background history, drug and alcohol testing, basic clearance kinds of information, would also likely inform the divination of a qualified individual. In spite of the broad language and coverage of the prospective pool of customers constrained by this licensing (any organization the President's team views as critical to national infrastructure), I think that many of the most appropriate candidates for this type of work might well opt-out.

As a last critique, I would refer you back to a May, 2007 article on StorefrontBacktalk, by Evan Schuman, titled PCI Efforts Crippled By Inconsistency, Conflicts . In it, along with other salient points, Evan describes the frustration and natural conflicts that occur with interpretation of a standard by experts who will naturally have a variety of biases, regardless of certification. In this case, the tests for PCI compliance are fairly well defined, but there is vastly uneven compliance interpretation, due to the expertise, the experience, and the inclination of the auditor. One cannot rely on a license to an expert as a substitute for knowing what the organization, itself, should be doing.

The real problem that the Cybersecurity Act of 2009 should address is an overwhelming lack of detailed understanding, emphasis, and engagement with security in the contracting organizations, not a lack of expertise on the part of practitioners. Much of the weakness we see in the news arises because of incomplete requirements, incomplete testing, and fundamentally inadequate definition and assessment of the security of these systems. Instead of creating yet another unsustainable regulation that will bring more pain than benefit, direction should be given to enforce better requirements, acceptance testing, and performance criteria that are driven by security.

Cybersecurity does require action in 2009, as it has for many years. Effective legislation should focus on asserting the requirements for security, and the variable definitions for security, and integrating that knowledge with the tens of millions of machines, applications, databases, and users, that rely on them everyday.