Suitable Security

Three Questions to Avoid Suffering in Security

2009-06-26T05:10:00.000-07:00

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

2009-06-19T20:31:00.000-07:00

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

2009-05-08T08:06:00.001-07:00

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

2009-05-06T20:05:00.001-07:00

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

2009-05-03T20:24:00.000-07:00

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:

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

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?

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

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

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

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?

2009-04-16T19:47:00.000-07:00

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

2009-04-13T20:46:00.000-07:00

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.

Guest Blog Over at the Knowledge Exchange

2009-04-13T14:01:00.001-07:00

People sometimes forget that the rock thrown in the pond can send ripples to shores you haven't even seen. Breaches are like that, and when I was asked by Jan Stafford at SearchSoftwareQuality to give my view on the current state of the Heartland Payment Systems breach, I did.

Your Company's Reputation: Critical but Fragile

I hope you like it.

Not so shocking news on the Grid

2009-04-09T04:54:00.000-07:00

On Wednesday, the Wall Street journal announced that:

"Electricity Grid in U.S. Penetrated By Spies

While this is not good news by any stretch of the imagination, it may be a stretch to consider it new.

The power grid and its SCADA control components have long been viewed as a likely area for attack, but one that was somewhat naturally less obvious to attackers. Partially this is because the systems themselves are unusual, in as much as they were mainly purpose-built for their jobs, and because the Grid-support IT networks were traditionally disconnected from common internetworking. In the late 90's, it was evidently thought that this was largely sufficient to deter the aimless hobby hacker, but in my experience, few people in the space thought that these systems would be able to withstand focused attention from a dedicated and well-trained force. Built to control many physical aspects of our infrastructure, they were highly segmented and seen as mostly unattractive targets. It was hoped that the natural evolution of IT systems and security to the Grid would beat the motivated attackers to the playing field. It looks like the hopeful timing was off.

Another reason for an expectation of this kind of breach is the insufficient language in the protection charter and mandate of the regulating authority, the North American Electric Reliability Corporation(NERC). Many utilities currently disagree over the scope of authority within the NERC charter, and there is far too much room for interpretation within the NERC Critical Infrastructure Protection Standard (CIP-005). The blending of dedicated, isolated, and connected networks, has rendered the network topology-dominated language meaningless, and new and more definitive wording is certainly called for.

In July of 2008, after discussions with various federal and cyber security bodies, the NERC made clear that it recognized the import of these concerns, issuing a statement which included a comment from the NERC Critical Infrastructure Protection Chair, Barry Lawson, which said,

"NERC’s ongoing efforts to improve its ability to respond quickly and efficiently to cyber and physical security threats are critically important to reliability of the bulk power system and the CIPC continues to be supportive of their successful execution.”

These efforts included increasing NERC cyber security expertise and reviewing and revising their standards. As we have all learned through the process of improving security in retail, financial, private, and public infrastructures, this type of improvement cannot happen overnight. This disclosure must immediately further energize and educate those new regulatory efforts.

The incursions themselves are described a little too generally to know whether or not to be more nervous than most of us in the industry have always been. Part of the announcement describes malicious code droppings and information gathering, but it is hard to discern whether these artifacts were deposited by embedded employees and insiders, or whether they were the culmination of a successful external attack. That said, the source is perhaps less important to many, as shown by a real-time WSJ spot poll which shows that about two-thirds of the poll-takers are "VERY" concerned about a cyber attack damaging US Infrastructure.

While it is clear that there exist weaknesses within the Grid, it is also pretty clear from the reporting that the incursions were not identified during a regular review process by the grid providers. With the widespread adoption of more and more mobile computing, and with the increasing demands for more flexibility and reporting within the consuming public, it is vital that this type of rigor rise to top of mind in the planning and expansion of all of the IT infrastructure supporting them.

For those of you who have begun to pay attention to the Smart Grid space, which I have written on before, take some comfort that concern about security is prevalent in many of the early Smart Grid discussions and roll-outs. Given the bi-directional nature of both production and messaging within the new infrastructure, and considering the use of highly configurable technologies like wireless and open-source platforms, the rapid evolution of these supporting security elements is well-understood to be key. For those interested, I would recommend looking at the work currently ongoing in the Advanced Metering Infrastructure Security working group, and to the updates you can find in the Smart Grid News, both of which are great sources to get up to speed on some components of these issues.

While it is natural to become very nervous when it looks like there are outsiders seeking to manipulate something as vital as our power, we need to stay focused on the processes and policies that will more systematically look for, identify, remediate, or even prevent, their recurrence. The interest in these incursions cannot end with their specific remediation, because it is equally likely that numerous others still lie undetected within the system. With new efforts at visibility, and with the promise of the development of a new infrastructure composed with security as a main consideration, these issues can be productively dealt with and hopefully avoided as we move forward.

New czar, New regulation, Not so new...

2009-04-01T05:43:00.000-07:00

As happens every few years, there is new federal focus on cybersecurity. In legislation announced formally on April 1, 2009 (though it was openly discussed for two weeks before), Senators John D. (Jay) Rockefeller IV (W.Va) and Olympia Snowe (ME) have proposed a new level of federal activity in cybersecurity. Comprised somehow of language within two separate bills, the proposed legislation, created with input from the White House, would create a new National Cybersecurity Czar position, reporting directly into the White House. According to published reports, such as this one from the Washington Post, it would also imbue this new organization with broad powers to mandate security, to enforce new regulations, and to actually disconnect non-compliant networks from the nation's infrastructure.

I have contacted the offices of both Senators over the past couple of days for more details, and as yet have had no response, so I don't want to even hazard a guess as to the real meat of the legislation. It is always difficult to know exactly what will survive in the legislation once it has passed through the venerable and tested sausage grinder of Congress, but unless someone has found a way to convert political posturing into pork shoulder, the output may well be pretty unpalatable for all of us. I would like to present some historical and factual reasons that explain why I think that further centralizing this responsibility, and then adding to it some broad regulatory and enforcement powers, is just plain wrong.

It isn't as though the government has a good track record here

I remember working, in 1997, to generate information about potential critical infrastructure cyber disasters; a small contribution to a very large effort which resulted in the formation of the Presidential Commission on Critical Infrastructure Protection, and then President Clinton's Decision Directive (PDD-63) which described a forward-thinking plan for understanding, mitigating, and monitoring, weak spots in the various industries upon which we all rely. In the PCCIP report to the President (Entitled "Critical Foundations: Protecting America's Infrastructures"), PCCIP Chairman and retired Air Force general Robert Marsh wrote:

"We found no evidence of an impending cyber attack which could have a debilitating effect on the nation’s critical infrastructures. While we see no electronic disaster around the corner, this is no basis for complacency. We did find widespread capability to exploit infrastructure vulnerabilities. The capability to do harm—particularly through information networks—is real; it is growing at an alarming rate; and we have little defense against it." Robert T. Marsh, October 1997

(By the way, that is an excellent document, and worth a read, even now, more than 10 years later.)

PDD-63 followed quickly and confirmed the risks and the goals:

"I intend that the United States will take all necessary measures to swiftly eliminate any significant vulnerability to both physical and cyber attacks on our critical infrastructures, including especially our cyber systems." President William Jefferson Clinton, May 22, 1998

There was a great deal of work, Information Sharing and Analysis Centers were stood up, and the general level of understanding was raised. Noted commentator and now author, Richard Clarke, drove initiatives as one of the first figures like a cybersecurity czar, but in time the excitement died down, organizational willingness to change slackened, and what was left was an institutional awareness, good avenues of information sharing, but only incremental progress.

Then came the tragedy of September 11th, 2001, and cybersecurity interest was more muted, overcome by the very real issues of physical and national security that the horrible crime exposed. It would be February of 2003, before the next major presidential level program in cyber security, President George W. Bush's National Strategy to Secure Cyberspace In this, President Bush, as President Clinton had before him, called out the challenge:

"In the past few years, threats in cyberspace have risen dramatically. The policy of the United States is to protect against the debilitating disruption of the operation of information systems for critical infrastructures and, thereby, help to protect the people, economy, and national security of the United States.We must act to reduce our vulnerabilities to these threats before they can be exploited to damage the cyber systems supporting our Nation’s critical infrastructures and ensure that such disruptions of cyberspace are infrequent, of minimal duration, manageable, and cause the least damage possible." President George W. Bush, February, 2003

It brought more attention, and more funding, to federal cybersecurity efforts, but there was still widespread acknowledgement that the solution was still clearly evading the effort. There were multiple efforts, among many groups, to address the problem, but without a concerted goal in mind.

Now arises this new legislative effort, with a quote from Senator Rockefeller:

"It’s an understatement to say that cybersecurity is one of the most important issues we face; the increasingly connected nature of our lives only amplifies our vulnerability to cyber attacks and we must act now.” Senator John D. (Jay) Rockefeller IV, April 1, 2009

Almost 12 years, and the problem sounds almost the same.

The problem is not enforcement, it is understanding

Security is not a simple thing to get right. It has many facets and therefore many kinds of weaknesses and strengths. Sometimes, the security challenge is keeping people out of networks, sometimes it is ensuring that they can get in. Sometimes it is keeping data from being seen, and other times it is ensuring that it is accurate so that everyone gets the right view. Because of this, security has never lent itself to the simple description, regulation, and enforcement that is possible in many other areas. This level of nuance makes the federal government among the worst arbiters of what is appropriate, and how problems should be handled. The conflicting priorities of ensuring practical security programs and progress with justifying budget and effort, lead to over-simplification of tasks, and of successes. In his remarks on the new legislation, Senator Rockefeller said,

"You have to keep making higher walls."

While this simple metaphor may resonate with voters and the press, the reality is that it is far more practical to approach the problem from the inside, by understanding better what protection is necessary, and if there are ways to reduce the need for these walls by being smarter about how we build within them. This type of thinking and expectation setting ends up biasing the language of success and of investment to areas which may well be sub-optimal

And in the enforcement vein, there are now hearings in the House on the need for and utility of the Payment Card Industry's Data Security Standard. The PCI DSS has been one of the single most influential and prescriptive security standards in history, and while PCI compliance demonstration and assessment remains an issue, there is little doubt that it has truly advanced industry protection and thinking. That does not preclude, however, congressional examination of its effectiveness. What is troubling, is the style of the examination, because it illustrates the potential disconnect in governmental action in the space. In her prepared remarks of March 29, 2009, Congresswoman Yvette D. Clarke (NY) questions the utility of PCI, closing one section with the statement:

"The only way to reduce breaches is by continuously testing and attacking a system through penetration testing and timely mitigation."

Really? While no one would argue that testing in this fashion is important, I don't know of anyone who actually understands security, who would ever make or approve a statement like this. That style of testing does little to solve issues of insider threat, data exfiltration, and theft of systems, among a litany of other inadequacies, but it is, like the wall metaphor, consumable by the press and public. Cybersecurity, for all of its importance, is unlikely to ever be so clear cut.

Current insecurity requires more understanding than enforcement

I guess that this is my chief gripe about this whole effort. For years, organizations like NIST, DHS, the NIAP, the NSA, the Air Force cybersecurity teams, on and on, have pushed to better understand security and securing systems. It is a brutal slog, because almost every system is serving some need. Evaluating, remediating, or replacing these systems is never popular. When President Obama charged Melissa Hathaway with a 60-day review of cybersecurity, it was an important first step, an opportunity to gather some tactical insight about the state of the problem. Similarly, I still believe that the CSIS report is a good starting point for more discussion of programs that could materially improve security through better understanding of varying government functions and applications.

That said, to create legislation which attempts to create a new group that will set standards that no one has been able to nail down in 15 years, and then to enforce them, strikes me as an impossible, and even undesirable, objective. It is also a task that I see as secondary to the more common and tractable one of changing acquisition behaviors (in terms of integrators and vendors be required to deliver secure services and systems), and of creating much more specific and open recommendations for securing these critical infrastructures.

I think that the average American citizen would remember the administrations of President Bill Clinton and President George W. Bush as being very different from one another in tenor, ideology, execution, and focus. They did, however, agree with respect to a positive way forward in cybersecurity: They believed that the government's role was to facilitate better industry security, and to positively incent the behaviors that were required through the government's voice and purchasing power. They perhaps should have gone one step further, to specify the owners of these efforts, to eliminate the governmental infighting, and this may be a productive area for President Obama to address.

With respect to regulation, such as the new legislation reportedly describes, their directives were very similar:

"The incentives that the market provides are the first choice for addressing the problem of critical infrastructure protection; regulation will be used only in the face of a material failure of the market to protect the health, safety or well-being of the American people. In such cases, agencies shall identify and assess available alternatives to direct regulation, including providing economic incentives to encourage the desired behavior, providing information upon which choices can be made by the private sector. These incentives, along with other action, shall be designed to help harness the latest technologies, bring about global solutions to international problems, and enable private sector owners and operators to achieve and maintain the maximum feasible security." President Clinton, PDD-63

"Federal regulation will not become a primary means of securing cyberspace. Broad regulations mandating how all corporations must configure their information systems could divert more successful efforts by creating a lowest-common denominator approach to cybersecurity, which evolving technology would quickly marginalize. Even worse, such an approach could result in less secure and more homogeneous security architectures than we have now." President Bush, National Strategy to Secure Cyberspace

They both rejected regulation except as a narrowly targeted last resort, and that is the way it should stay.

Of Tylenol and Telecom

2009-03-30T17:40:00.000-07:00

I was struck today by Chris Williams' article in the Register, "BT network 'vulnerable to Chinese attack'" regarding a new dust-up around access nodes and optical equipment purchased by British Telecom from Chinese manufacturer Huawei. In comments from Alex Allan, of the Joint Intelligence Committee, the acquistion, in combination with People's Liberation Army former research head, Ren Zhengfei, at the head of Huawei, has given rise to a series of concerns about the security, propriety, and safety of this equipment.

Following up on a mention of other Huawei/Government conflict within the article, I found this piece from the NY Times on the dissolution of an offer by Huaweii to purchase 3Com, in cooperation with Bain Capital Partners, based on a concern over the likely US Federal Government intervention given the popularity of the 3Com TippingPoint iron in trusted government installations. In this report, Ileana Ros-Lehtinen, the ranking member of the House Foreign Affairs Committee, said that the deal was one that “threatens the national security of the United States.” As though somehow ownership by a company within a foreign nation would unavoidably result in the tainting of the equipment in some unique and malicious way.

Trust me. As you have read here before, I am not one to overlook the possibility of malicious code in equipment, packaged software, and even through the open source community. I would, however, like to draw a little bit of even-handedness into the discussion, because I believe that ordering the words like this, "Chinese-developed" "Vulnerable/Malicious" "Software" places far too much emphasis on pandering to a generalized fear of that which is foreign, as opposed to a more balanced view: Fear of that which is software. In this case, at least according to the reporting, it is the fact that the maker of the equipment is headquartered in China which makes this equipment acquisition a headline and an issue. The real issues should be quotes like this one, "ministers were told...the unspecified measures would not mitigate built-in vulnerabilities", which would naturally apply to almost any equipment, of any vintage, from any country, because so little of it has ever been looked at to identify those vulnerabilities.

So what does Tylenol^TM have to do with any of this? To my mind, the approach taken by Johnson and Johnson, the makers of Tylenol, during the Tylenol Scare of 1982, makes for a simple and elegant model for BT and any other firm to follow. For those of you who have forgotten, in 1982, there were 7 tragic deaths resulting from victims taking tainted doses of Tylenol capsules. Someone had opened the capsules and filled them with cyanide. Facing this tragedy, an unknown assailant, and a general public potentially exposed to more tainted product, Johnson and Johnson recalled it all, about 31,000,000 bottles, and instituted new methods of tamper-resistance: in manufacturing, in packaging, and in user-visible seals. Tylenol's brand recovered, and no more people were injured (with the exception of a woman who was reportedly a victim of a similar attack in 1986, at which point Johnson and Johnson permanently discontinued capsules as a product). This example can provide guidance to firms concerned with their own component and service safety today.

#1: Don't go looking for a subject to blame.
If the unthinkable happens, and you have predicted it, blaming someone else does not lessen your responsibility. If there is malicious code in this equipment, then it is the responsibility of those who buy and deploy it to find it and mitigate it, or otherwise they must remove it from the shelves or from service.

#2: Come clean immediately.
This does not mean a warning that potentially tainted equipment was deployed, it means admitting that the process of procurement ignored this potential issue, and that in the future this mistake will not happen. This admission is vital to provide confidence that the threat has been understood and either mitigated or eliminated.

#3: Improve the process.
Tamper-resistance was pretty much brand new in 1982, and yet Johnson and Johnson retooled their manufacturing to implement it, and now we find it on everything from pharmaceuticals to bottled water. Creating acquisition and validation policies that will similarly analyze and certify software seems no more daunting that a complete sea-change in physical manufacturing, so there is little excuse for not getting started.

#4: Don't make the problem any worse.
If there is really concern over this, and not just idle hand/flag-waving, then do something about it. Stop using the devices until you can verify that they are clean. I am not suggesting that one switches to a domestic product, rather that whatever product is chosen be chosen with this level of inspection in mind.

#5: Stop creating bogeymen to blame.
Whether it is China, or Cyber Jihadists, or Anarchists, or bored teenagers, the reality is that software development, support, and maintenance has become such a diverse melange of new, old, open, and outsourced code, that it is almost equally likely that there will exist maliciousness in any of an organization's applications, regardless of their source. How much development is sent off to be outsourced, how many consultants or contractors touch and application, and how many packages are truly vetted to ensure that they have not been corrupted, prior to application deployment? Far too few.

The recent disclosure by the Joint Intelligence Committee and this ensuing discusion should be put to the most positive use: It is an example of our urgent need to examine our applications for "poisonous" code with a rigor similar to that which we use in the areas of food and pharmaceutical safety. If we do, we can become more certain of our security, regardless of our sources.

Old Security Habits and the New Smart Grid

2009-03-23T06:23:00.000-07:00

This weekend brought us a new security vulnerability message about next generation power, wrapped in the traditional trappings of today's Internet and cybersecurity messaging. The CNN headline reads, "'Smart Grid' may be vulnerable to hackers", and the story looked like any of a hundred similar flags waved over software applications, newly delivered services, government infrastructure, etc. The news was that a security firm, IOActive, had worked with a noted researcher, Travis Goodspeed, to implement and demonstrate exploits around potential weaknesses in the new Smart Grid infrastructure. The thrust of the article, and others, like this one, by Robert McMillan at InfoWorld, is that the Smart Grid is now showing itself to be vulnerable by virtue of smart meter vulnerabilities. Recommendations for resolution, from IOActive and others involved in the security consulting business, are to require third-party audits of these systems prior to their deployment.

I think that model is wrong. I am not saying that third-party testing isn't important, but it misses the underlying problems that have allowed the insecure system to exist in the first place. Systems like the Smart Grid need to be developed with a fuller understanding of the purpose, threats, and environment, in which these components will be working.

The report from IOActive does not detail the exact vulnerabilities that are exercised in their report, but a couple of online articles point to work that Travis Goodspeed did in identifying a vulnerability on a specific micro controller. From his blog :

a stack-overflow exploit targeting TinyOS 2.x on a Tmote Sky wireless sensor node, which uses the Texas Instruments MSP430 micro controller

which is a micro controller reported to be used on smart grid devices. This blog post was written over 18 months ago.

I have two concerns, if this is the way in which Smart Grid security is undertaken and understood:

Flaw-oriented Security: In flaw-oriented security, effort and focus are like the spotlight in an old prison-break movie. Alarms sound ("Prisoner is Loose!") and the searchlight moves to the escapee, following him around until he is either caught or escapes over the wall. During the time that the light is on him, the rest of the yard is dark, all the guards are training their attention on him, and the rest of the prison and grounds are pretty much up for grabs. In security, this can be related directly to the evolution of the Internet security model. First it was the perimeter, then the vulnerability assessment systems, then the detection systems, and on and on. The searchlight kept moving, but the vulnerabilities, and the attackers, knew how to move out of the light into an area without the illumination and focus.
Testing-Oriented Validation: In a testing-oriented security culture, either components or full systems are assessed for security prior to deployment or in a simulated environment. This is critical, but it is neither sufficient, nor is it efficient on its own. A simple analogy would be to automotive testing. Everyone has seen crash-test commercials, which are done at the end of manufacture, but few would recommend that as the first test. Even if you move back a step to the system level, like the brakes, one does not wait until the full brake system is installed to see if it will work. Each component, to as discrete a level as is possible, is tested prior to assembly to both simplify the test and any diagnostics in the case of failure. This level of analysis also allows for the definition and enforcement of critical performance criteria prior to component construction in terms of functionality and tolerances.

These two concerns highlight the requirement for a new style of thinking around Smart Grid security which centers on planning for the success, and the benefits, of the Smart Grid. This entails much more than securing these building block components. The visualization of security must include the expected expansion of both deployment and capability that are foreseeable even now. Google has continued to advocate and make progress with its Google PowerMeter initiative, which while a data-consumer at inception could easily grow to be more proactive. In the existing "proactive" category are companies like Tendril, Inc that are creating technologies to facilitate the sharing of data and control between providers, grid, and consumers. There are others, responding to the requirement for interactive technologies. In the words of Dan Delurey, Exective Director of the Demand Response and Smart Grid Coalition,

“Wide-scale smart grid development requires many different enabling technologies all working together to provide value and scalability to utilities that in turn translates into consumer engagement and empowerment."

One of the primary missteps that has caused the greatest security pain during the ongoing evolution of Internet-enabled business and services has been a lack of foresight. Organizations didn't (and many still don't) consider the risks of connecting various systems to the Internet, and didn't think about the nature of the information that they would be likely to share in the future. Even today, applications are rolled-out without sufficient thought to their internal architectures, and their likely exposure of client and internal data.

The Smart Grid cannot afford the same stumbles as the Internet has had, and must take a more thoughtful approach to technology choices. Components must be specified, and then validated, according to the critical characteristics of such a core utility, and with a substantial sense of gravity to balance reality against the excitement and hope for the new power infrastructure. Configurability, features and speed to market, must be tempered with consideration of reliability, security, and recoverability, and that validation must occur before these systems are either settled upon in roll-out plans or actually implemented.

Do we believe that we can't win?

2009-03-20T05:05:00.000-07:00

After all of these years in the security industry, I had thought I had picked out my favorite sector vice: The all-t0-frequent "Let me show you how ignorant you are." attitude of many security technology experts. In the 1990's it was flavored with "Think you are secure? Let me hack you and humiliate you.", and more recently "You say you are compliant? Let me show you how that was a complete waste of time."

These approaches always made me kind of sad, because I think that security is supposed to be about using unique experience and expertise in security to help others who have other skills (commerce, marketing, technology, art) to be protected as they engage in their own interests and businesses. I never understood why embarassing other people was a good way to get your point across.

But, it looks like this is now going to fall to number two on my list of annoying security practitioner habits. At a panel discussion on March 17 at the National Press Club, a group of respected vendors organized into the "Secure Enterprise Network Consortium" delivered the following message:

"If people want your data, they'll get it. Sorry."

Wow. Now that's depressing.

The panel had been put together to respond to concerns about national cybersecurity. Florida Rep. Jeff Miller had given the keynote, describing concerns about supply chain security, a real area of interest given our growing trend towards offshoring the development of so many components of the national and private infrastructure. In Representative Miller's words:

"There's a growing concern that major manufacturing for many mission-critical semiconductors have moved off-shore, primarily to Asia, and the inherent risk associated with procuring electronic components that have been designed, fabricated, tested and packaged in unsecure facilities abroad demand a well-planned and a structured response."

It strikes me as the start of a discussion around what safe means, what the trade-offs are, and how to use a variety of technologies to mitigate risk.
The responses, at least what I can gather from Bill Jackson at FCW, and from the Congressman's press release, were not that. To quote Wayne Fullerton from Cisco:

"Certainly, we should be building into this a baseline protection of information, but we should be going into that with our eyes wide open that if, in fact, somebody really wants that information, no matter what you build in as the baseline, the information can still be gotten. So we're really building a level of comfort."

Comfort? That doesn't sound good. I am reminded of C.S. Lewis' quote on comfort, "If you look for truth, you may find comfort in the end; if you look for comfort you will not get either." I agree.

With all these years in security, I cannot disagree with the premise that a motivated attacker, through human and technical methods, may well find a way into a system. I do, however, reject the conclusion that this reality should change our expectations from our vendors and ourselves.

The problems of securing information are not unknowable nor are they incurable. Anyone who has examined the clean-up process of most incidents knows that there arises a laundry list of reasons why the attack succeeded. This list, while sometimes lengthy, is real and knowable and actionable. Sometimes it calls for better background checks for employees, or encryption of sensitive data, or strong authentication into networks and applications, or maybe integrity checking and validation of components and transactions.

This is by no means rocket science, it is just tedious, sometimes disruptive, and definitely not as easy as resetting your client's (or your nation's) expectations. We cannot allow our expectations to be lowered to the point that we no longer demand that providers of products, services, networks, and information, strive to be truly secure.

What insights can Wolverine bring to security?

2009-03-18T05:44:00.000-07:00

I had the privilege of spending a couple of invigorating hours at MIT last week, discussing Smart Grid security practicalities with a couple of brilliant guys who combined deep roots in power, software, and control systems with a very forward-looking view on improving the security, efficiency, reliability, and scalability of our national power grid. In the course of that discussion, I learned a good deal about how challenging it can be to design software for space missions, where software, hardware, and sensor failures must be mitigated by other software, hardware, and sensors, without the guiding hand of their creator.

As I was driving back from MIT to Waltham, I naturally began the translation of all of that information into the context of security, and began to ask myself some questions about the real nature and purpose of security, particular for systems and services for which predictable performance are key and about the possibility of re-orienting some of my thinking. A good, legal, definition of information security can be found in the US Legal Code, Section 44, which says (in part):

The term “information security” means protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide:

Integrity

Confidentiality

Availability

The revelation for me, from those discussions, was that the ultimate goal for many systems is just to be able to do what they are supposed to do, undeterred by security problems. These systems don't want to have to protect themselves, they would rather just endure the attacks and continue to function as they should. It would be as though they were potentially impervious, but more likely imperishable. That line of thought brought me to Wolverine.

Wolverine is a character in the X-Men series, and as this image (Taken from the LA-Times site) shows, he has some unusual accessories built into him, mainly a skeleton and claws made from a fictional and indestructible metal called adamantium. So what does this have to do with security? While his metal pieces and corresponding strength are important, the only reason that it was possible for him to have these accessories installed was because he is self-healing. Basically, he regenerates all the time, so that installing a bonded skeleton, or hacking him up, won't end him. He heals and he moves on. Sure, he fights back, he does his own hacking of others, and he attempts to defend himself, but at the end of the day, he mainly endures because his system knows how to put him back together, pretty much no matter what the comic book or movie writers throw at him.

Isn't that much of what we want from software? When we discuss security, whether it is of the electrical grid or of our credit card providers, we would like the system to consistently behave the way we expect it to. This means that I want to be able to turn on the switch, or to swipe my card, and have the right things happen. I want the lights to go on, I want to buy something, and I don't want to get zapped, and I don't want to get robbed.

Creating software that is capable of this level of reliability is obviously a very difficult challenge, but it is one that has seen very little innovation outside the design of high-reliability systems and the application of high-quality software programming practices. There are some areas which occur to me that are ripe for consideration in presenting this more regenerative, less defensive, approach to security. Here are a couple:

Network-based Data Exfiltration and Malcode Insertion: In the case of many system hacks, (see a good recent piece by Byron Acohido) attacks involve the presentation of unexpected data causing either disgorgement of extra data or changes to the underlying system. Were the application to know more about how it was supposed to function, it would be unlikely to allow itself to execute this kind of instruction, whether that meant recognizing that it was inappropriate for a Login screen to return scads of data, or for a Point-of-Sale application to execute commands to change the system configuration. Instead of, or in addition to, attempting to filter out these attacks, the application could be more aware and active in interdicting the outcome.
Promiscuous-mode Sniffer Installations: A few of the recent high-profile breaches have been enabled through the insertion of traffic sniffers on unencrypted internal networks. These largely passive drivers are very difficult to locate on the wire, and provide a clear channel to otherwise trusted network traffic. If the software which either drives or monitors the operating system would recognize that reconfiguring network adapters on non-system/network management machines to view all traffic, and not just traffic intended for their viewing, was out of line, those adapter changes would not be allowed. Or at very least, if the change was made, it could be discovered, flagged, and rolled-back, by a system that understood how it should function.

This is not meant to call for a complete recasting of our thinking on security, but to introduce some additional fodder. Thinking about "What should I expect?", "What other data can I use to recalibrate myself?", and "What should I never do?", are realistic intelligence that can and should be brought to our construction of software and systems. This is especially true when the failure of the system will cause the failure of something much larger, whether it is a transaction service, a communication system, or our power. By looking past Wolverine's ability to actively battle and defend, and focusing on the character's real strength, the innate ability to recover, we can potentially re-evaluate some of our own thinking about security.

A Lightweight Model for Appropriate Security Cost and Effort

2009-03-15T20:26:00.000-07:00

When asked about the actual meaning of the word context that I throw around so much on this blog, I encourage people to use a rational lens into the amount of protection that they need based on the amount of risk and value that they perceive to be associated with a particular asset.

I relate the need for this assessment, prior to jumping to security implementation conclusions, because this balance is a critical step in the security process that many people miss. I often use the work of Judge Learned Hand (what a great name) when I speak about security and liability, but it is helpful to treat Judge Hand's efforts as the bright line of appropriateness that we must straddle, trying to keep from falling into negligence on one side, and expensive delusional security paranoia on the other.

To keep it brief, Judge Hand was a real father of Tort Law thought, and in a case revolving around a drifting ship (U.S v Carroll Towing), Judge hand created a fundamental premise for the Tort judgements that would come after. In what was called, "The Calculus of Negligence", Judge Hand documented a relationship between responsibility, likelihood, and damage. In short, he ruled that if the cost of preventing an event is lower than the product of the likelihood of an event multiplied by the cost of the damage, then you are negligent if you are not preventing that event. This is very useful to determine when you are not doing enough, but I would add the Danahy extension to Judge Hand's seminal work which is this:
If the cost of preventing an event is much higher than the product of the event likelihood multiplied by the cost of the damage, then you would be much better off investing the extra money in the protection of something else, because something else doubtless needs more protection.
Understanding this relationship brings us to a need to create a common methodology for understanding and measuring these ratios. In the litany of sources that are consistently passed around, I would recommend that a good place to start is (no shuddering) a government standard, called FIPS 199. While there will be much that instinctively causes many to think that this is probably not the right model for them, I'd differ. I am not saying that it is perfect, or that one can use it in its parochial form for any group, but the model is sound, and extremely helpful.

Speaking to security in its more primal terms, the standard recommends that assets be considered as having the traditional security properties of Confidentiality, Integrity, and Availability. Impacts are then measured according to the likely result of an impingement against any one of these. For different services, or data elements, or other assets, a better understanding of these criteria help to ensure a much more balanced and holistic approach, without the unfortunately commonplace experience of too much security in one place, the wrong security in another place, and no security at all in other's. Here are two examples:

In this example, the system under analysis is doing bookkeeping, for which both confidentiality and accuracy are critically important. While availability is important, one can almost always perform these functions at a later date in the case of a transient failure. Given the importance of these two characteristics, and the overall criticality of the system, the appropriateness test encourages a pretty robust investment of time and resources to ensure that this system is kept whole.

In this second example, My Blog, clearly confidentiality is not an issue, as I hope that everyone comes to read it. Integrity? Yes, I would like for any errors or controversial viewpoints to be my own, but I would not invest a ton of time or money to prevent someone from posing as me, or introducing their own comments, as I could clean them up later. As to availability, I would like it to be up and readable, but I know that people can circle back if I am simply down for a while.

It is typically the case that data or system categorization is viewed as an examination for areas of weakness, and to identify holes in security policy or practice. I would recommend using the same methodology to advance security thinking, to balance it, by considering the possibility of another insight: That too many resources may be in place in one area that could reasonably and appropriately be put to better use somewhere else.

A New Venue, and a New Test, for Security

2009-03-10T18:10:00.001-07:00

I'm not sure how many of you are aware of the term "synchronicity" as anything beyond a dated Police album, but here is the way that Wikipedia describes it:

Synchronicity is the experience of two or more events which are causally unrelated occurring together in a supposedly meaningful manner. In order to count as synchronicity, the events should be unlikely to occur together by chance.

Today I had a very unique experience of this, and it revolved around security and our national electrical power infrastructure (the Grid). In as much as I am more a believer in Chaos theory than synchronicity, I have come to the conclusion that this is likely because there are many lesser known events, trends, and developments, that are bringing this issue to my attention, and they deserve some cycles.

I was about to hop on a webinar, when my friend and colleague Andy Bochman (author of popular blogs on energy policy in the DoD and on alternative energy for the Discovery channel ) sent me a recent article looking for my thoughts on its impacts. The article was about a January 2008 speech given by CIA Analyst Tom Donahue at the SANS 2008 Scada Summit in New Orleans. Mr. Donahue revealed that the CIA was aware of cyber attacks which had taken out power in multiple non-US cities. His revelation and the furor which followed it faded from view pretty quickly, from what I could find online, so I gave it a quick browse, set my bookmark for later, and started up the webinar, entitled "Top 10 Security Breaches" by Davi Ottenheimer at ArcSight. Within 30 minutes, Davi was reporting that his number 2 attack in the top ten was this same quote from Mr. Donahue, and its implicaitons.

This was enough for me, time to power up.

For those of you who aren't aware of it, there is a vast array of technology that supports our electrical power system, from generation through distribution and metering. It is a phenomenal example of "just-in-time" delivery, as electricity must be consumed at basically the same moment that it is generated. The scale of these systems is massive, with currently over 300,000 miles of wires, and more than 1,000,000 Megawatts of generating capacity. It is like an orchestra, with that capacity being delivered through over 9,200 entities, all working in concert to minimize any shortages (brown-outs) or outages (black-outs) to the tune of 99.97% availability.

We rely so totally on our electrical distribution system, that any disruption plays havoc with our core industries. According to the Department of Energy, these costs are monumental. A single hour of outage in that hit the Chicago Board of Trade resulted in $20,000,000,000,000 (yup trillion) in delayed trades, and the blackout we experienced here in the Northeast in 2003 resulted in a $6,000,000,000 (billion) economic loss.

The security of these systems was once much more easily managed and understood by those practiced in that market. SCADA (Supervisory Control and Data Acquisition) systems offered management and insight to simplify the tasks of regulating power generation, and automated responses to various critical and near critical conditions. Typically run on isolated networks, and operated more like manufacturing systems than network-based control platforms, the SCADA systems were suddenly brought much closer to the world by pervasive internetworking. New devices, from internet-enabled switches to PDA-based system control software increased flexibility and responsiveness, but have created and broadened the threat surface to include many parties external to the actual power generation facility.

It is this capacity to connect and control that makes non-SCADA, more traditional security, a concern in the space. It was what popped out to me from Mr. Donahue's comments, that:

"We do not know who executed these attacks or why, but all involved intrusions through the Internet."

This encroaching vulnerability was identified very early in the critical infrastructure/cybersecurity lifespan. As early as 2002, and maturing into guidance issued in 2006, and 2008, the North American Electric Reliability Corporation ( NERC) was issuing guidance, including an assessment of cyber assets.

All of this is important, and a definite work in process. There are extremely capable SCADA professionals, and many of them are contributing to efforts to better secure those systems. Good examples of this work exist at the DOE's Sandia Labs, which sponsored a forum on the topic of cyber attacks on control systems this past June. This information is going to help to standardize and raise awareness of preventative techniques and coming threats. But this is mainly about creating or solidifying protection against the existing, almost 100-year old, power system.

What I am learning more about, and what I look forward to discussing, is the next (r)evolutionary move in our electrical energy infrastructure, the Smart Grid. Incorporating the power and pervasiveness of the existing grid, with the user interactivity of the Internet, and the configurability of a cloud-computing service, the list of opportunities and challenges is too good to ignore.

Integrating existing networking models and architectures with something as fundamentally required as power will be one of the most basic tests that security can be put through. Can technology be used to maximize the benefit and effectiveness of a core infrastructure service, to protect our industries and our homes, while improving our performance, efficiency, and energy conservation? This is a test worth passing.

Would We Sign the Fed's Security Report Card?

2009-03-09T08:32:00.000-07:00

I remember as a kid that while my grades were always pretty good, I had some occasional difficulties in the "Conduct" section of my report card. I was highly encouraged to curb any of the offending behaviors by the fact that my parents, unamused by my in-class efforts at improv comedy, would need to see, understand, and then sign my report card before I returned it. The reason was pretty simple. I already knew I was less than a model student on occasion, so the report card was reporting little news to me. It was, however, bringing some new insight to my parents, who were responsible for my upbringing, and who could make changes (yowch) to their own efforts so that next time, my report card would reflect genuine improvement.

Last Wednesday, the Office of Management and Budget (OMB) released its 2008 annual report on government agency performance under FISMA, and there was, once again, some improvement, and some continuing under-performance. The specific line-items that are examined within the yearly audit have names that sound comprehensible, and they are, by private industry standards, relatively modest. There are two issues to be addressed as a result of these ongoing reports, with the first being the actual performance, and the second being the translation of that reporting into concrete actions.

Improving the grades of the various organizations is complicated, both because of the massive scale of many federal operations, and also the lack of real consequences for organizations that end up behind the acceptable range of the curve.

This is not to say that individuals have not borne some unpleasant outcomes from these reports, because some have. The problem is that federal operations are long-lived, populated by a combination of career civil servants, political appointees, and wealth of consultants and contractors. These annual report cards point to systemic problems, issues which will require years to resolve, and multiple year programs can run into continuity problems given the nature of the teams attacking them. Because of this, the assignment of the relevant responsibility requires a similarly systemic lens to be placed upon the reasons for these inadequacies.

FISMA itself is a very detailed beast, and this is not meant to be a discourse on FISMA and its characteristics. As often happens on the blog, this post is about seeing the data a little differently, and about finding out the right places to take responsibility and action. In as much as there is motion in these measurements, noting them, and watching what happens as a result, will help to inform a different path in the future.

Privacy of data is central to FISMA, so examining a direct rating on a privacy component is instructive. Within the FISMA report, there exists a rating against the organizations' "Quality of Certification and Accreditation Process". This includes reference to a concept called "Privacy Impact Assessment (PIA)". According to guidance provided by OMB on the privacy provisions of the E-Government Act of 2002, this presents:

"an analysis of how information is handled: (i) to ensure handling conforms to applicable legal, regulatory, and policy requirements regarding privacy, (ii) to determine the risks and effects of collecting, maintaining and disseminating information in identifiable form in an electronic information system, and (iii) to examine and evaluate protections and alternative processes for handling information to mitigate potential privacy risks."

So, to paraphrase abruptly, this is the rating of how organizations are doing in terms of protecting private information that they may be in possession of, or that they may receive. This is pretty important, given the current climate of increased data sharing, and expected interconnection called for within the President's economic stimulus plan, such as the Health Information Technology initiative.

Summarizing the data, in 2008, only roughly 30% of the agencies received a "Good" or "Excellent" rating, which is the same number as in 2007, but down one from 2006. At the same time, the number of "Poor" or "Failing" organizations has shrunk from 6 to 2. The majority of organizations fall within the "Satisfactory" bucket, but I cannot find a definition of what Satisfactory" (or "Good"/"Excellent"/"Poor"/"Failing") within the document or the associated documentation of FISMA.

Admittedly, some organizations, like the Department of Health and Human Services (HHS) have a detailed description of their own PIA process, but it is hard to understand what the relationship is between this relatively deep and seemingly rigorous process and the organization's drop, in 2007/2008 from "Good" to "Satisfactory". It is difficult to know whether there are more systems, more weakness, less controls, or something else.

And this is where a report card system breaks down.

The FISMA reporting through OMB is viewed every year as a sort of waterline, a generic aggregated index into the federal government's position on data security, and relative motion by organizations is noted and discussed. The problem is that without context for the motion and for the previous rating, it is very hard to know whether to push for some new action, to insist on continuation of existing projects, or to simply applaud.

The idea of these types of ratings is solid, "You can't manage what you can't measure", but in this case, there needs to be a better understanding of the underpinnings in order to decipher what they are telling us. Without that knowledge, and without a sense of confidence that the actual measures and performance are relevant to the risks for each group, it is hard to be comfortable in either the results, or the system.

Data is the Target: Our Roundabout Path to Material Security

2009-03-06T06:56:00.000-08:00

The security industry has often times been tasked with a variety of protection goals. In its earliest incarnations, internal and proprietary networks were a focus, and the intention of security was to both harden them and to protect their traffic from view in the event that eavesdroppers could connect themselves to the networks. This resulted in the first encrypted networks, used mainly in defense and government operations. This was long before pervasive internetworking (Arpanet/UUNet/Internet) really existed or were broadly available. In these early days, the industry could have found its language and its voice in protection of data (which encryption clearly provided), but the discussion, and the vocabulary, turned to protecting networks. Encryption was thought to protect the confidentiality of the network, and the data was therefore similarly protected. The language had been chosen, and the language of security followed, to the harm of both our understanding and investment as we attempted to secure ourselves and our customers.

In the 1990's, internetworking swung wide doors, and introduced the reality of incursion by untrusted parties. The rapidity of adoption, and the mixed experience of the population connecting conspired to define a simple solution to the problem, "Put barriers (firewalls) on the networks", and the semantic momentum moved fully behind a much more physical metaphor. The goal was established as keeping people out of networks, or detecting them once they entered. The idea that the data itself should be rendered unreadable was shelved, as organizations invested in technologies that they hoped would ensure a sanitized network environment housing only a highly trusted population. It did not take long for this ideal to be undone.

The network protection model was overcome by the complexity of network connectivity and the insecurity of so network components (applications, connection points, user behaviors like passwords). The detection model did not stand up for long, either, quickly overcome by the sheer volume and heterogeneity of traffic in an era of gigabit networks with anonymous and global subscribers. While still offering value as a blunt instrument protecting against Denial of Service attacks and monitoring network traffic, it was clear that network protection/detection was necessary, but by no means sufficient.

Enter the next phase of network hardening; the use of encryption and strong authentication to create virtual private networks. Ranging from the proprietary to the widely distributed (like WEP and SSL), network authentication and encryption technologies created a means through which data could be secured when traveling over the wire or in the air. Used in infrastructure to create broad, multi-protocol pipes, and in applications to create function-specific hardened channels, the network had become opaque, but the endpoints, the sources and sinks of critical information, remained unchecked. Ironically, when traveling between an organization's office buildings on a public network, these encrypted networks provided more protection than was had when the data actually arrived at its destination on an unencrypted internal network or host disk drive.

Which brings us to the more-or-less present. In spite of the implementation and investment in all of these preceding technologies, and in the presence of a far more skilled and experienced base of technologists, organizations continue to leak data in massive amounts. The losses can be from credit cards, personal histories, or industry proprietary data. This is because security's momentum has still not really found it's ultimate best direction, which is perhaps its most primitive, the protection of the value in this food chain, the data. It isn't that products and processes don't exist to provide protection, and it is not that people aren't familiar with the risks, it is that individuals and organizations oftentimes either underestimate the exposure of a network or application, or overestimate the universal understanding that data elements must be secured.

Great examples of this disconnection are everywhere, whether we look for it in current events (breach descriptions), or current best practices (lacking). One such example is the PCI DSS standard. Developed to help organizations to better understand and to better enforce security around payment card data, it is quite clear on what data must be protected. As a specific pointer, In requirement 3.2.2, the standard says:

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

But later, in the section on technologies (Requirement 6), there is no language about testing to ensure that data is not stored, or is stored safely, and the language which does exist about protection is sadly vague on the appropriateness of the varying technologies:

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

This disconnection between recommended security technologies, and the actual requirements for data security are a glaring weakness in PCI specifically, and a general weakness of this type of requirement documentation. There needs to be a clearer assessment of the appropriate validation of protection of data, and a new effort to direct that protection to be as close to the data elements as possible. When one looks at the number of times that credit card numbers are stolen from organizations that view themselves as compliant with this standard, you quickly realize that there is a substantial disconnect between the goal (don't store this) and the accepted or recommended means of verifying (test the application for security) that that goal has been reached.

To protect data is to protect the asset that is of most value to both the owner organization and external attackers. Protecting access to the network and watching for unusual behaviors are good secondary behaviors, but the very first step that an organization must take is to identify all of these data targets, and to ensure that they are adequately secured in their own right, if organizations are to take the first meaningful step to improving their security.

Security as an Enabler in Health Care

2009-03-03T17:37:00.000-08:00

It is easy, when we are constantly involved in the business of protecting organizations, systems, and people, from harm, to forget that security is not just a painful cost center. It is so much more that just finding a way to staunch the blood flow of stolen information.

When security is understood during the inception of something new, it actually makes innovations possible.

While doing some further research on the President's new Health Information Technology initiative, I ran into one of those voices, one that is considering something brand new, which would/will be impossible to do without good security. It is worth considering this as an example of ground-up security thinking, because it doesn't exist yet, and it must be secured, and it will never be secure, unless it is from the very beginning.

In an article entitled: "The Politics of Health Care: Change Can't Happen with Technology Alone", Dr. Michael L. Cowan, MD presents a view of health care in the near future. It is health care that is "democratized" by a patient's access to information and providers, and it is health care that is often delivered through virtual means that are not available today. As I read through it, and as I take Dr. Cowan's charge to heart, I am struck by the role that technology will need to play, in concert with a new way of thinking about health care, which is the meat of Dr. Cowan's proposition.

At the same time that I am enervated by this visionary view of health care, my security self begins to outline the dangers, unasked. The pervasive sharing of information that would expose our most personal weaknesses and histories is one, and the likely availability of financial and insurance information to the unscrupulous who could extract services or payments at will. As examples, there is the Akron Children's Hospital breach in 2006, and then there are the celebrity record thefts, like that which affected George Clooney in 2007. Research shows that medical identity theft is even more profitable than that of credit card data, due to fraudulent claims and services.

So, back to the enabling:

Understanding the Data, Upfront
This one is easy. Systems that will be built to accommodate the vision of more interactive and accessible health care will naturally be handling private data. While it is obvious that an individual's identity and treatment information must be secured, so, too, must their interaction with the system when looking for advice on specific ailments. This entire system can become an open and interactive system, so long as the user's anonymity can be protected, and so long as the details of their history, and the pattern of their new requests, cannot be associated with any knowable individual. It speaks to a network of trust, and the type of obfuscated identity that allows the patient to connect the dots, but which would appear chaotic to the external observer. Components can be found in one-time use authentication, federated security models, and the use of strong encryption for any assembled and identifiable data.

While it is possible that there will be some amount of non-personal data that will be handled by these systems, (generic health care content), the system should first be designed to process the critical private data, and then only provide unsecured access to very particular resources.

This type of access is enabled through security practices and technologies, and can extend the range of these private services well beyond the doctor's office.

Enabling the Flexibility
Security technologies also provide the means of differentiating access communities between doctors, service providers, and users. Individual architectures and systems are not necessarily required, nor are their expense, with the introduction of appropriate management of users, roles, and access. In the idealized environment, a doctor in a hospital anywhere, can access the records of a patient in a hospital anywhere. As well a patient who falls ill far from home, would be able to locate and share their records with any practitioner. For less serious illnesses, a patient would be able to access symptomatic information, seasoned with his/her own medical history, to understand likely seriousness and remedies for the condition. Again, it will be security technologies that enable this interaction, doing more than just protecting it.

New technologies and new models are rapidly changing the face of health care, voting, retailing, and socializing. If we can build these new systems with security in mind, while continuing to shore up the insecure systems of the past, privacy and convenience may sometime find themselves not at odds, but in harmony.

Knowing Where Data is, and Where it Might Go

2009-03-02T04:08:00.000-08:00

On Saturday, Pittsburgh's WPXI reported on the discovery of technical information and plans about President Obama's new helicopters on a computer in Tehran, Iran. The discovery had been reported by Tiversa, a Pennsyvania-based P2P intelligence company.

First, good for Tiversa, which can use this event to bring more awareness of unintented data leakage (exfiltration), and good for security in general, because it provides a very useful lens into the ways in which our understanding of data placement has become so much more important.

Locating and Understanding Data

I've written before about the need to both identify and categorize your critical data. Prior to acquiring any technologies, and prior to rolling out sweeping security change, it is of primary importance to take the time to map out what critical data is present, and how it is being handled.

This event, though, and risks associated with file sharing and P2P in general, point to another task on the security team's docket, understanding the secondary systems or services that may have connection and access to a system containing important data.

Many people overestimate the familiarity of users with system architectures and the shared nature of many of the data storage and communication resources that they possess. Unless an organization has taken the time to truly segregate the users and privileges on a system, accidental exposure can be a logical byproduct of leveraging costly iron across multiple personnel. In the case where such sharing is necessary and natural, there are a couple of simple steps that can reduce the likelihood of unintentional exposure.

(NB: In systems where the comingling of inexperienced or uncontrolled users and highlighly sensitive data is unavoidable, the data should be handled as though it were on a public system, using strong authentication and encryption at all times. That is a topic for a different post. )

Configuration Control, Auditing, and Enforcement
The installation of most risky forms of sharing are more or less individual actions on the part of users who are looking for some new functionality, or who are convinced that they can improve their productivity or satisfaction with a new piece of software, or with a new means of communicating with their friends. P2P is a great example, but other include things as simple as instant messengers, facebook applications, and games.

There are multiple technologies that can help in this effort, but the major ingredient here is to set the rule and to enforce it. Enforcement can be done through a hardening of the target operating systems, and through the use of monitoring technologies for changes in their configuration. Examples would be tools like tripwire, ncircle, solidcore, and others. Similarly, the reality of system access by social networking sub-applications should be explained. These applications should only be used on individual systems, and then, only within a defined set of behaviors.
Configuration control must also extend to transient systems, like laptops connecting. A random user's P2P can instantiate itself within your network, and open up a channel that will be short-lived and difficult to find.

Education
When users and administrators understand that there is going to be sensitive information on the system, and that their actions can very well put it in danger, they tend to behave with more caution. Whether it is not downloading game programs to office laptops, or not visiting questionable sites from the corporate network, a sense of propriety about company systems can lead to more responsible operations. At the same time, education on the organization's rules of the road and enforcement criteria for system sharing can also be a powerful disincentive for those who might still make bad decisions.

Alarms
New products in the data loss prevention (DLP) space can help to identify data exfiltration very early, and can be used to identify the systems from which the data is being taken. Examples of DLP tools include Vontu, Orchestria, Liquid Machines, and Code Green Networks, among others. While these approaches may not prevent all exfiltration, it is likely that they will enable interdiction before the damage is too great.

In this blog I write and comments frequently about the need for more awareness, and more awareness, and more awareness. In this recent event, it looks like some unwitting individual set up a P2P system, without thinking or knowing about the possibility that it could be co-opted to steal data that it had not originally hosted. That individual will pay the price, as will others involved in the food chain. Here, as in so many other posts, technology is not the key to protection, but it can be used to help with education and awareness, so long as those goals are established and highlighted first.

Security Starting Points

2009-02-28T13:08:00.000-08:00

Usually following a speaking engagement, or when I get introduced in some technical forum, the question comes from somebody about the right place to start in implementing security. Some of the people who care are newish CSO's, some of them are business people thinking of how to get more secure, and some of them are analysts or press, responding to their own readers.

For my part, I think that I get asked the question because of my background. For better or worse, I've worked on most of the mainline technologies that people are familiar with. Secure distributed computing at HP in the 90's, then building the security services at BBN/GTE/Genuity, then started a secured kernel shim company called Qiave, that was then bought by the firewall appliance company Watchguard, and now my new company (Ounce Labs) produces a family of products that analyzes software for vulnerabilities. So most people come to me looking for an answer about which product category/class to start with. I disappoint all of them.

Three Questions to Avoid Security Suffering
Asking "What product should I start with?" is common, but is about as much use as approaching your doctor and asking her, "What medicine should I take?". Unless you are displaying some extremely obvious symptom, her answer is likely to come in the form of questions, and questions are always my response. The following are my first three, in no particular order. There are, of course, tens or hundreds that could be applied both within, and in addition to, these three, but these give a great start.

Question 1: Why are you doing this?
In my experience, no one comes to the decision to be secure because they have had an epiphany and now believe that security is up there with purity, charity, and chastity. It is always because something has happened. It can be because they just took a class, or attended a webinar or seminar. Maybe they were breached, or found out that a company in their space had been breached. Often, they are simply asked to do it by a manager, or an auditor, or an executive. Depending on what the motivation is, the first steps can be different. If they have been breached, clearly they need to complete whatever triage and clean-up they are performing, and need to establish a means of both protecting against re-infection or re-emergence of remnants of the same exploit. This means that my short answer to them is that they need to think about why they are interested in security, and then start of by understanding the reasons why they are not secure enough yet. This provides a much more focused goal for them, and also gives them a language and context to talk about their security within.

Question 2: What are you trying to secure?
This is a question that is usually particularly enlightening about, and for, individuals newish to the space. The gut reaction in many is to answer "my networks", but when pressed, or when given more time to think, they may answer "my data", "my business", "my reputation", or "my time". Depending upon their actual goal, the answer to this question leads to a litany of others, about the specifics regarding whatever body of resources they are really looking to protect. Security is among the most murky disciplines in the entire technical catalog, and it requires this kind of self-examination to get a handle on what is actually needed because in an absence of a real strategy, it can be argued that anything will make it better,but few organizations just want to get better, they want to be at least good enough. Good enough is very related to what is actually supposed to be secured, and how secure it has to be.

Question 3: (AND THIS IS THE BIGGIE) What will happen if you don't do this right?
Human nature, or at least the noble components of it, incline us to want to do the right thing. I think people ask advice about security because they actually want to be better informed and do a better job. This is all to the good. Unfortunately, in many cases, the yearning for security tends to cool pretty abruptly when confronted with the chilly reality of funding, incovenience, and change. Security is not free, and good security is neither cheap, nor convenient. In general, I don't get this question from people who have been doing a lot of security for a long time, so any of this will mean change, and change can be painful.

At the start of a new security process, or at the start of an extension to an existing security program, it is very important to ask this question, because knowing whether it is imperative or interesting will make all of the difference in the choices that should be made. If failure will mean loss of jobs, and revenue, and reputation, then there will be pretty robust support for the person who wagers their career on creating an effective means of addressing all the issues, even if those means are not easy. If, on the other had, failure will mean that someone's status report is yellow, or that the managers need to sign a waiver, or that a vendor gets a very strongly worded letter, the security champion should keep that in mind when he or she finds it necessary to either push hard and escalate, or compromise and close on the issue.

Security is not a word with a strictly defined meaning, and so it must always be approached situationally. These questions, and all those that they will in turn engender, will help to set up an environment in which there will be a balance between the intention for security and the likely willingness of the organization to help to make it a reality.

Five rules to saving money by avoiding security shelfware

2009-02-25T21:24:00.000-08:00

I had an excellent meeting today with a senior team at a major bank we were visiting here in Dallas. They had decided to recommend our product, which is always nice, but I was most impressed with the way that they had arrived at the decision.

Prior to engaging with any vendors, or even doing any deep analysis of the available products in the space, the team had first thought hard about what they wanted to accomplish. They actually took the time to figure out what their goals were, before asking vendors how they could help. Having done that, they generated an appropriate set of criteria, researched vendors in the space, and then selected trial candidates who were then contacted. The trial itself was similarly thoughtful, managed without intervention from vendor teams, to allow the organization to experience the solutions the way they likely would on the day after they wrote the check. There was no way they would be stuck with shelfware.

Shelfware is an unfortunately common purchase for most firms, and security shelfware is a prime offender. Given the range of security products, their varying purposes and qualities, and the experience-level of a generally inexpert buying population, security tools are consistently purchased with excellent intentions, only to provide security only for the dust mites that end up hiding behind the boxes in forgotten closets.

With a few basic rules, this wasted expense can be avoided, and both capital outlay and embarassment can be kept to a minimum.

Rule 1: Look internally before you look externally
Most security programs are created or extended in response to some new internal dynamic in an organization. There has been a breach, there is a new standard, or a new executive is concerned with the publicity that has been surrounding security issues. Before looking to the technical press, or worse, looking to vendors, for recommendations, figure out what the root problem is. Remember that companies in the security space have invested their time and effort in a form of protection that they think is important, and so you should first decide what protection is important to you before you find out what is available. Entering into discussions with vendors too early can easily sway your thought process to what is in front of you, instead of what is best suited to your problem and your organization.

Rule 2: Look for value that matches your needs, not just for value
At dinner tonight I heard the term "Vulture Vendors" from a CSO I had just met, referring to the horde of companies that contact a firm if they have a public security incident. He sounded both amused and a little frustrated that each of these firms were reported to present themselves as a solution to the breach, though they would have no insight into the underlying causes. I told him that my opinion was that security is just sort of like that. As an example, take any of the recent credit card data thefts. I can imagine calls from disk encryption vendors, VPN vendors, system integrity vendors, DLP vendors, authentication vendors, IDS/IPS vendors, etc. all coming through with a variant of that message. Disregarding the possibility that the calls were completely disingenuous spam, there is value in the discussion from all of them, because each can help with some part of this type of problem. An unprepared buyer would quickly find themselves trying to decide "Which solution will provide the most protection for my dollar", as opposed to the really important questions, "In my organization, which of these solutions will fit best, and will address the internal problems I know that I have." Often, there is more benefit to be found from questions about how solutions will ultimately be used, and how they will fit, than there is in questions about the product's feeds, speeds, and features.

Rule 3: Look for vendors with compatible customers
Having taken the time to understand and clarify your goals and internal needs, you will begin the process of contacting the vendors, and one of your very first questions should involve their experience with similar organizations, and discussions of their customers who are solving similar problems. This should be done by presenting the problem that you are trying to solve, without exposing the details of your expected approach, as this can skew the discussion. Assuming that the vendor is not a brand-new startup, someone is using their products. Describing their successes, and ultimately connecting you to their champions, brings two substantial benefits to your decision-making.

First, you will learn about their clients' view of the problem space. Their approach may be similar or different from yours, based upon their own internal workings, but you will likely take away a refinement of your lens on the problem and on the potential value of the solution. Second, by connecting with the customer, you can get a better sense for their actual use of the product; any additional strengths or unexpected difficulties that they have found, and their view of the real benefits they have accrued. A passively positive or incomplete view of the implementation/integration of the solution should ring some alarm bells about potential difficulties in deriving full value from the purchase.

Rule 4: Try before you buy, and buy only what you know you will use
Think of the product you are going to purchase as though it were a new entree that you are going to be bringing home for dinner. Even if you can read the ingredients, you would certainly want to taste it before you buy it, to make sure that you will enjoy it. Assuming that it is fantastic, you probably don't want to buy a pallet load, even if they offer you a 50% discount, because you are unlikely to eat that much of one thing before it goes bad. Products are the same way.

Product presentations and demonstrations are good, but real-world implementations within your environment will show so much more about the likely benefits to your organization. While many groups see this simply as a way to verify product claims, there is even higher value in knowing that your team can run it, that it does not disrupt adjacent processes or products, and that you will be receiving the value you expect when it is used internally.

Do not buy more than you need simply to get a discount. It is a sad reality that even highly succesful initial implementations will take longer than expected, and therefore acquire only what you are likely to need to achieve your goals. While addtional units purchased upfront may be at a reduced cost, unused product is a loss, and that loss is compounded by the cost of ongoing maintenance on uninstalled products and the likely need and costs to upgrade these additional units when implementation does finally happen.

Rule 5: Partner with your vendor for success
This isn't just a trite throwaway. While the occasional unethical salesperson may rejoice in unloading product on your doorstep without a further thought about your use of it, healthy companies and sales teams recognize that it is the long term success and adoption of the product that will bring the greatest value. For this to happen, you have to demand it, for lack of a better description. You should expect your vendor to check up on your roll-out, and you should factor some implementation assistance during your negotiations on a final purchase. The involvement of the vendor can save weeks of frustration through their body of institutional knowledge regarding work-arounds, optimizations, and generally practical advice regarding the use of their product from their customers.

Security products are not unique in their capacity to befuddle customers and render themselves to troublesome to deploy. They are, however, a special kind of shelfware, because if they sit unused, a weakness that had been identified as needing protection remains wide open, and the organization continues to be at risk.

First Look at the Draft of Government Top 20 Security Controls

2009-02-23T20:19:00.001-08:00

As mentioned in my earlier alert, a new draft guideline (Concensus Audit Guidelines) for security controls has been released for comment by a group of governmental and private cybersecurity organizations, headlined by former AF and DoE CIO, John Gilligan, and the well-regarded SANS security team.

You can find some interesting data around the formulation of the problem and solution spaces in two powerpoint presentations available through slideshare. The first is lead author John Gilligan's presentation of the difficulties of managing governmental cybersecurity, and is called, "Ensuring Effective Security, the CIO's Dilemma", while the second is from Alan Paller, director of research at SANS, and is called, "Consensus Audit Guidelines", focusing more on the use of data from succesful offensive strategies to maximize defensive posture.

The new draft document, described today by Alan Paller, as "the best example of risk-based security I have ever seen,' is quite comprehensive and provides a very unique blend of traditional network security, application and software security, and design-level security concerns. Unlike other attempts to document and characterize a common suite of best practices, this new approach also takes the time to separate the low-hanging fruit from the strategic goals, and to provide guidance on enforcement and audit techniques.

Overall, I think that the approach was well thought out, and I will be submitting my comments on the direct content through the approved mechanisms. There is however one area that I think is worth spending a short amount of time on, and that is the introduction of a potentially fatal paragraph to the document's noble purpose:

"Furthermore, CIOs and CISOs must balance business needs and security risks, recognizing that there are sometimes trade-offs between them that must be carefully analyzed and measured."

And at this point, I begin to worry. This codicil, within the introductory section on relationship to other federal standards, screams "WAIVER". Without providing the appropriate guidance on how to balance risk, likelihood, cost, and security, an under-informed but well-meaning team will almost always err on the side of hitting the date and hoping the system will not be caught short by an attacker who finds a known or unidentified weakness.

George Orwell described this human weakness in the Partisan Review, in the Winter 1945 issue:

"People can foresee the future only when it coincides with their own wishes, and the most grossly obvious facts can be ignored when they are unwelcome."

For the past 20 years, it has been obvious that security needed a more active and aggressive stance within the federal government (as well as almost everywhere else). But, whether in the government, private industry, or even software vendors, the decision has been routinely made to do what is possible within the current budget or control environment, and the waiver the rest of the secure behavior requirements. This has led us to the situation we find ourselves in now.

Let us hope that by the time the draft period has ended, someone will have been able to articulate the proper methodology for that balance, so that any decision will benefit from both business context and from the remarkable heat and pressure that a new and enforced regulation can bring. We know that business needs change and mature, but a bad decision to forego security in support of a transient business requirement tends to linger, and continue to corrupt, for a very long time.

If you are interested in advancing this strategy, please take a look at the document, and get comments to the appropriate folks, (John Gilligan at jgilligan@gilligangroupinc.com or SANS at cag@sans.org ) by March 25th. It is a good start in an important space with a dedicated and experienced team behind it.

ALERT: New Controls Document Out for Cybersecurity

2009-02-23T12:28:00.000-08:00

Nice Job John Gilligan (and team)

Today was released the first draft of the government's new effort to better secure cyberspace, through the recommendation of a new series of controls. It is called:

"Twenty Important Controls for Effective Cyber Defense and FISMA Compliance"

I am still going through it for the detail, but so far it looks good, including configuration, application software security, and a real defense-in-depth view of the problem.

Give it a read, I'll be back on this tomorrow.

Cyber security and the lessons of Hurricane Katrina

2009-02-23T07:19:00.000-08:00

There was a good piece by Keith Epstein in the Business Week Tech Beat section last week, reporting on some statements made by Paul Kurtz, a long-standing resource on government cybersecurity and a potential candidate for President Obama's cybersecurity lead role.

His quote, as called out in a darkreading piece by Kelly Jackson Higgins, was:

"Who is in charge [in the event of] a cyber-Katrina?"

Now this would be a good second question, but its prominence, and the fact that the coverage of Mr. Kurtz's remarks all appear to focus on the value of a FEMA-like cybersecurity clean-up squad, is to me an unfortunate and shallow interpretation of the lessons that could be learned from the Katrina disaster, and from the suffering that befell those affected by it.

The primary lesson from Katrina that cybersecurity advocates and experts should learn is to:

MAKE THE LEVEES STRONGER
(Period)

There is a good, and short, piece on the evolution and challenges of the New Orleans levees on the National Geographic site (here). It details the process, if you can call it that, through which the height of the levees was raised over time. Basically, the levees were first built to a height, and then in 1947 and 1965 big storms came and flooded the city. After each storm, the levees were raised a little more. So the process was, build, flood, raise, flood again, raise, rinse, repeat. According to Lt. General Carl Strock, chief of engineers for the Corps of Engineers, quoted in the piece,

"It was fully recognized by officials that we had Category Three [hurricane] level of protection. As projections of Category Four and Five were made, [officials] began plans to evacuate the city. We were just caught by a storm whose intensity exceeded the protection that we had in place."

The insufficiency of protection is attributed to a relatively straightforward equation. The likelihood of a storm that would breach the levees is low enough that congressional funding (or local funding) is not provided to address the vulnerability. In as much as building levees is expensive, takes years, and is so locally-focused, that decision is politically understandable, although retrospectively awful through all of those lenses.

So, here is the analogy.

Katrina devastates one of America's most colorful cities because, among other reasons, the protections in place are not sufficient. Better protections would have been expensive, so the political infrastructure has rolled the dice, hoping that a category 4 or 5 storm won't hit while they are in office. It comes up craps in 2005, and multitudes pay the price.

It would be hard to argue that people think that our cyber-environment is adequately protected. It gets hammered, some minor tweak is made, everyone complains and sues, then it is forgotten until the next major hit. Morris worm, DDOS, Code Red, Nimda, XSS, Confickr, etc. People are damaged all the time, records are lost, id's are stolen, time is wasted at a breakneck pace.

All of the indicators are there. There is no doubt that the protections are insufficient, there is no doubt that the storm is already raging and damage is being done by all of the breaches happening to the system. There is also no doubt that almost everyone can see the waterlevel rising. Unlike Katrina and the levees, you can not use predictive models to explain away insufficient protection. There are major storms flooding network neighborhoods every week. Probability of those events is 100%.

The government should not be creating FEMA for cyber-disasters to clean-up the damage, when they haven't yet had the resolve or taken the initiative to first more fully examine the possibilities of avoiding them. Instead of FEMA, the government needs to create a Corps for cyber security, because even though the Corps of Engineers may have been given the wrong decisions regarding the correction of the levee problems, they at least were in the position to see the potential disaster and point.

Retrospective on Katrina shows us that more investment would have made an enormous difference, and that political careers and real people's lives were ruined by inaction. Rest assured that as cyber disasters continue and grow in impact and exposure, similar ruination will also likely follow.

Security and Open Source Software

2009-02-19T07:24:00.000-08:00

There has been a real furor lately regarding the security of Open Source software. I think that the entire debate is missing the real point, and I'd like to offer a different, and much less argumentative tack.

(It should be noted that one of the major critics of Open Source software in this discussion is Fortify Software, and Fortify Software is a major competitor with my current company, Ounce Labs. If you think that makes my commentary useless, and eliminates my capability to add value to this topic, then please stop reading now so I don't have to delete your comments about my bias later when I moderate them out of existence. For the record, Fortify makes a good product that developers use to identify security flaws when they are building software. Ounce and Fortify are the two leaders in the most recent Gartner magic quadrant, and depending on whether you are focused on developer errors or enterprise security issues, you will likely choose one or the other products. )

With that major parenthetical aside complete, and with my conscience clear on the topic of transparency, you might think, given the companies' similarities, that I will be agreeing with the Fortify position, which is, from their press release, that "Rising Enterprise Adoption of Open Source Software is Putting Businesses At Greater Risk".

I don't agree at all.

I think that this conclusion is intentionally overblown, unhelpful, and is used to draw attention (which it has) to the Fortify software and service business. What is worse is that the marketing tool (you need to analyze your open source software because it is especially full of badness) got compounded by a sales tool; Richard Kirk, the Fortify VP and GM of Europe. His quote, as published on the it-director.com site (here) is this (emphasis added):

"Our own research, however, has concluded that open source software exposes users to significant and unnecessary business risk, as the security is often overlooked, making users more vulnerable to security breaches. That's not to say that commercial software isn't without risks, but any flaws on commercial applications tend to get patched a lot faster than on open source, as the vendors producing the software have a lot more to lose than an open source programmer," he added.

Open source software is not monolithic, some is good, some is not, for some security is important, for others, not so much. Significant and unnecessary risk is much more dependent upon the purpose and context of the application's use, than on any inherent security characteristic. As a result of the hyperbole in this statement, made in relation to the UK Conservative Party's report considering limiting IT spending and leveraging Open Source, (some basic info here), there was only more heat generated: People argued that Open Source was more secure, or less secure, or just plain wonderful, or really quite evil.

Pleagh.

Here is my take, sans vitriol, and sans axe-to-grind.

I like open source. Ounce has contributed some maven work, some hudson work, some fixes to open source applications we found problems in, and we have released a whole framework under open source licensing for people to use in leveraging our product in new ways (Open Ounce - O2).

I also just like the idea of open source. Great programmers who have passion for a task can create some pretty excellent stuff. At HP in the late 80's and early 90's, we had "skunkworks" projects, where we would build, on our own time, things we thought would be useful or interesting. Open Source spreads that goodness around. Unfortunately, all of this benefit and good spirit doesn't mean that Open Source can't or won't have some badness in it.

The reality is that virtually all software has some amount of vulnerability within it. Depending on who you felt comfortable offending, and where you thought you could best capitalize, you could create any number of plausible, demonstrable, scary pitches:

In-house software is full of vulnerabilities. Your programmers are stressed, they are building off of older code that is likely insecure, and your core business is banking, or retail, or whatever, so you are not going to be super-proficient in secure development.

Shrink-wrapped software is full of vulnerabilities. They are rushing out the newest version, they want to encourage you to upgrade, and look at their history: They always have to patch their software.

Outsourced software is full of vulnerabilities. Those programmers in foreign countries will not develop code as securely as we do in (insert home country here), and there may be malicious code injected.

From this story, Open Source software is full of vulnerabilities. Because they don't live inside a formal SDLC, and because they don't mandate specific tools usage, and because they don't patch the same way as shrink-wrappers do, they are more vulnerable.

Truth is, there will be vulnerabilities in most all of these, and the path to a real solution is not to simply point at the groups that provide the software, but rather to point at the groups that buy, and therefore set the priorities.

Organizations must strive to get the best value that they can for their software dollar, and part of that equation must be security. To do that, software from wherever must be checked the same way, by either the vendor or the purchaser, to ensure that it is secure enough to use. It is not about demanding that the programmers use a specific tool (I'd support waving a dead cat over code while murmuring the words to "Born to Run", if that would make it secure), it is about demanding that organizations do not run any code that they haven't validated for security.

Pretending that security is some virtue that one kind of software has, and that another kind of software is genetically incapable of possessing, is a lie, and is dangerous in that it lends a sense of comfort to the software types that are not being criticized.

Open source software can be a real value, and can be assessed through reasonable means to ensure that it has, (yes I'll say it), suitable security. Have at it.

Massachusetts backpedals again on data protection regulations

2009-02-18T11:36:00.000-08:00

There is no doubt that information security, and particularly data privacy, is not easy. It is also, however, hard to debate that the theft of private information is not becoming the next cottage industry for information age attackers in this century.

In keeping with these realities, the State of Massachusetts created a demanding set of rules to encourage and enforce secure treatment of personal data, with a variety of original deadlines from January thru May of 2009. Included in these regulations were Executive Order 504 and 201 CMR 17.00 (this the final copy). Both started out with noble aspirations for privacy and responsibility that I have applauded before, but as of February 13th, there has been a fundamental weakening in the knees of the regulators, and in the language describing appropriate policy. Take a look at the release from the Office of Consumer Affairs and Business Regulation here.

It isn't just the slip in dates, (from May 2009 to January 2010), although that is a great example of pushing out the problem until it is even harder to solve. It is mostly the putty-like softening of the language. I can pull out several examples, but this is a blog, not a bog, so I won't bury you in more than one. One is enough. This one is related to third-party service providers who will also have access to private data, and who will likely be at least an arm's length from the actual transactions, and will therefore be less sensitive to it.

From September's version of the regulation (I've added the emphasis):

"(f) Taking reasonable steps to verify that third-party service providers with access to personal information have the capacity to protect such personal information, including (i) selecting and retaining service providers that are capable of maintaining safeguards for personal information; and (ii) contractually requiring service providers to maintain such safeguards. Prior to permitting third-party service providers access to personal information, the person permitting such access shall obtain from the third-party service provider a written certification that such service provider has a written, comprehensive information security program that is in compliance with the provisions of these regulations."

"Taking all reasonable steps to verify that any third-party service provider with access to personal information has the capacity to protect such personal information in the manner provided for in 201 CMR 17.00; and taking all reasonable steps to ensure that such third party service provider is applying to such personal information protective security measures at least as stringent as those required to be applied to personal information under 201 CMR 17.00. "

That is monumental weakening. from "contracts" and "certifications" to "give it your best shot" (a non-attorney's (my) interpretation of "has the capacity" and "reasonable" steps.) The way I see it, if people took the time to understand what was meant by capacity, or what constituted reasonable efforts, then they would already be part of the contracts and the certification. This just leaves sufficient murk and muddiness so that doing anything will likely be enough, and it will become a decade-long task for civil courts and future legislatures to have the backbone to actually define what these mean in practice. That period will be pockmarked by eruptions of private information, with sufficient blame and posing opportunities for all involved, to the betterment of no one.

By the way, I have earned my living making software for my entire career. I know how hard this will be, even just the starting of it. That is not an excuse for pretending this isn't important. By removing the hard requirements the State removes the major incentives for change, and the software industry and service providers will continue to do what they have done for the past 40 years. They will develop the software that they are asked for: faster, niftier, and easier to use. Until the requirements include, or are trumped by, "capable of actually protecting private data", then there is no reason why a business responsible to shareholders for satisfying customers, will ever prioritize security and privacy over simple functionality and performance. We can continue to look forward to the numbing pattern of data loss, finger-pointing, clean-up, temporary interest, ennui, then rinse and repeat ad nauseum.

Jaikumar Vijayan, in a recent Computerworld article (here) on February 13th, reported on the pressure applied by various business stakeholders, from the Retailers Association of Massachusetts, to Google and Microsoft. Maybe that is where we should begin to see the incongruity, that the Office of Consumer Affairs and Business Regulation is seen to have weakened the language, not because Consumers had a problem, but because the Businesses were uncomfortable with the Regulation. It is much like the situation if the Department of Industrial Accidents took more guidance from Industry, than from those representing parties injured in the Industrial Accidents.

I had hope that my home state, known for advocating privacy, equality, opportunity, and social justice, might actually stand by this position of protecting privacy and identity, and lead less active and aware jurisdictions to follow suit. I guess we will continue to be forced to look West, as California seems the only state to be giving data privacy, data theft, and identity protection, the attention they deserve.

Do we really want a new Internet?

2009-02-17T19:32:00.000-08:00

In a February 14 NY Times article ("Do we need a new Internet"), John Markoff takes a look at the ongoing evolutionary development of a next-generation Internet, and speaks with some of the players who are either interested in, or working on, the new net.

It is hard to argue with John's characterization of the Internet as a kind of rough neighborhood, and it is really pretty exciting to think about a new Internet that would arrive on the scene remarkably clean and largely immune to the tarnish and dangers that are plaguing today's internetworked environment. The problem is that today's network, with all of its permissiveness and its pervasiveness, is not at the real heart of the problem.

We are.

In her book, "Getting Organized", Stephanie Winston relfects on a situation that many of us wrestle with, trying to make order out of the chaos of a high-speed, high-input, high-tech life.

"Probably, as your life became more and more complicated over the years, you have occasionally been ale to step back and say to yourself, 'I am being self-destructive. I've got to stop this right away.' Whereupon you went through a period of intense, determined organizing that ended a day or two later when you discovered that nothing had really changed and you were right back where you started!"

In this example, the problem is clear. A clean desk, or a neat notebook full of lists, does not make any of us more organized, it momentarily gives us a new place to be unthreatened by heaps of paper, and by reminders of missed deadlines and pending disasters.

A new Internet will do little to eliminate the risks we see today, particularly if there is little appetite for changing our behaviors, or rolling to a new internet protocol. An example is the development of IPV6, which remains an interesting topic, but hardly mainstream.

There is a much hope invested in a new and shiny network, but the right approach is not to try to create a tabula rasa, even though the working name of the Stanford research program in this area is the "Clean Slate Project", with the following objective:

"The goal of the Clean Slate program is to reinvent the Internet to meet the needs of the future through fundamental and 'disruptive' advances, rather than incremental patches and work-arounds," said Guru Parulkar, the program's executive director.

History has shown us that it doesn't take long for human nature, human greed, and human laziness, to quickly trump the most sanitized conditions. We also know that with uncountable millions having been spent on traditional internetworking technologies and content, that the old and unsavory networks are not going anywhere. They will continue to leach corruption and compromise into any new environment.

In his work to confront a more pressing and tragic condition, poverty, 2006 Nobel Peace Prize winner Muhammad Yunus did not simply blame the victims of poverty for their presence in it. His analysis, and his approach of "Social Business", relate to improving the situation by rethinking our framework for approaching it:

"Poverty is not created by the poor people. Rather it is created by the economic and social system that we have designed for the world. It is created by the institutions that we have built, the concepts we have developed by the policies borne out of our reasoning and theoretical framework. In order to overcome poverty, we have to go back to the drawing board and redesign our concepts and institutions."

The insecurity of our experience with today's networks is created more by our blase' interaction with them, and our incomplete understanding of our own requirements, than by any core underlying weakness in the way that they were assembled. We need to start by retraining ourselves. We need to control our impulses for the quick and dirty, and invest in the secure and the sustainable. If we can agree to define what would make a successful security strategy for today's wild-west network, it will only serve to better our situation in the short term and provide us for good habits if a new and more secure network does ever show up at the door.

Can you clear all malware from networks? No.

2009-02-15T03:54:00.000-08:00

After one of my previous blogs, I got an email asking me about how I would recommend clearing a network of all of its malicious code. How you would "clear the swamps".

The simple fact of the matter is that you can't. Seriously. There are a couple of reasons, and let me start with one that is technical, and relates to current and historical sources of massive pain, packet sniffers. In many cases, packet sniffers are used to passively sit on a system and listen for traffic, recording everything. Encrypting your networks isn't enough, as they are often installed on actual systems where the data can be stolen post-decryption. They pick up passwords, and private data, and anything else that happens along, but do so without interrupting anything. Commonly these sniffers have been installed during an attack, or by a virus or worm. They are very hard to find, really only visible by checking settings on all of the machines on the network to see if the system is listening to all connections, or to all processes, not just the ones that it should be. Very hard, and time consuming. So eliminating all packet sniffers on a network today would be just about impossible, and that is compounded by the fact that more malware is hitting those systems, and it is likely that another worm or virus could corrupt the software shortly anyway.

But this discussion masks another real problem, which is that the threats are not all technical. Even if you could clear all malware, there will alway exist humans and partners on that network who need to access data to get their jobs done. A recent study published by CyberArk (here) indicated that over 70% of current workers would expect to take company data with them if they were terminated, and these are actual employees, not people who are planning to use their access for illicit purposes.

So, whether it is malware or contractors/employees/partners, it will be impossible to clear all of the threats, the listeners, off of the systems and the network.

So, back to the original question. I suggested that one drain the swamp before adding new applications, particularly the plan for the new Health Information Technology additions in President Obama's stimulus plan. This wasn't to eliminate all of the threats, but rather to be able to finally see them better, and to construct a system that would be secure in spite of these risks. "Alligator Alley" a nickname for a section of road crossing southern east and west Florida, was constructed through massive swamps which had not even been surveyed previously. The process of understanding, mapping, and compensating for the realities of the environment made that controversial project successful. It will be necessary to do a similar level of discovery, protection, and compensation, to create a centralized system of reporting through all of the technical swamps that exist today.

This protection will need to start with the applications themselves that feed this system. The best way to improve protection and decrease likelihood of losing this information will be to construct a roadway for it, and "information alley" through the untrusted common systems and resources. This means that the new enviroment will require:

Application-level network encryption. If an application contains and serves up private information, then that application must acquire it, store it, and then transmit it, through methods that it controls and secures. It cannot rely on meta-network or infrastructure level privacy mechanisms
Application-specific audit and access control. Knowing that there may be untrusted individuals or programs on a system, applications must ensure that they are doing their own checks, and not relying on the operating system to keep people away from private data. This means using internally controlled access to encrypted data, and using internal means to audit and report on any access to that data.
Application security assessment. Whether new, old, or open source, any application that will either access or control access to private data must be checked to certify that it won't simply roll-over when attacked or tapped by some other resident of the swamp.

The swamp is -not- going away. In reading the proposals, so much of it is geared towards improving the security of the network, or of the configuration of the systems. There is little acknowledgement of the need to also change our requirements on the applications that will run within what a new network that will also have many of the same risks and challenges that we see in the existing infrastructure today.

Security and Savings Through Smarter Acquisition

2009-02-13T13:57:00.000-08:00

In the recent study, ( "Securing Cyberspace for the 44th Presidency", published in December 2008 by the Center for Strategic and International Studies), there is a very refreshing new call for leadership by the federal government, leading by example through the acquisition of more secure products. On page 7, there is a very specific recommendation:

"13. The president should direct the NOC and the federal Chief Information Officers Council, working with industry, to develop and implement security guidelines for the procurement of IT products (with software as the first priority)."

This gives me a great deal of hope that there may finally be progress made in the improvement of systemic security, as it is my view that flawed applications, and improperly chosen or configured applications, are the most pressing weakness in our infrastructure (public or private) today. I believe this because I have created products and companies that have done most levels of security, from secure distributed architectures and platforms, to managed security systems, to kernel-level shims and encryption, to security testing and analysis. Through all of those years, the application remains the target, and weaknesses in networked applications can thwart otherwise excellent security precautions. In many cases, the application's role in information theft can be missed, because organizations are heavily invested in protecting weak applications, and those protections catch the heat. "They didn't encrypt their wireless, and so private information from their HR system was picked up by a sniffer on the wire.", or "An employee with internal access acquired the private information by copying files to a removable disk." In both of these cases, the application that either served up or stored the data should have been ensuring the data security, regardless of the environmental security that was expected to be in place. The application is at fault, either because it didn't work right, or because it should never have been chosen to fulfill that role in the first place.

So, it is very encouraging to see the CSIS Commission report actually highlighting acquisition of secure software where secure is defined by the application's purpose. When you get to the details within, it is (unfortunately) much more about secure configurations then securely constructed applications, but hopefully the actually regulation that might evolve will not be so parochial. (To be clear, I think that the focus on secure configurations is a valuable move as well. Just look at the work that was done under John Gilligan when he was CIO of the Air Force, that led to OMB’s Federal Desktop Core Configuration (FDCC). One of the best CIO's to have operated in the federal space, he led at both Energy and the Air Force, and his role in the new CSIS report is not headlined, but his contributions are obvious within. )

All in all, this is a first shot over the bow of technology acquirers, letting them know that they may well see recommendations or requirements for more explicit security in their program acquisitions of software. Let's hope that these recommendations to the President are taken seriously, and that private industry follows this lead. It drives responsibility and awareness of security more into the business cycle, making it far more proactive than it is currently. Buying more secure software is far more efficient that cleaning up breaches and patching weak software after it is deployed.

If insecure software becomes unacceptable, and not just undesirable, we will all benefit.

Keep New Data Out of the Swamps

2009-02-12T06:25:00.000-08:00

In thinking about the risk of information theft from the newly proposed Health Information Technology aggregator (See my earlier blog), I began to think about all of the difficulties that already exist in many of the systems that might well touch the soon-to-be-minted repository of our healthcare information. Corrupted networks and systems are like swamps, and attackers have dropped in alligators.

There have been several data breaches lately which have had, as their central enabler, some amount of malicious code placed on their systems. For those of you who enter this discussion without a lot of exposure to hacking and eavesdropping, the type of malicious code we are talking about is typically some form of listener or logger, that simply attaches itself to a computer or a network and then listens to communications and operations. These communications may be emails, or applications running, or people copying files. If you are interested in knowing a little more about these programs (sniffers or eavesdroppers) take a look at the computer surveillance entry at Wikipedia. Sniffers have been showing up quite a bit lately, and were publicly aknowledged as a source of the problems at Heartland Payment Systems. There is a great, lightly technical blog on the problem at Evan Schuman's blog, StorefrontBacktalk, that is pretty enlightening.

So what's all the fuss about swamps? Well, we know from fairly constant reinforcement that federal networks are frequently targetted, and frequently breached, in attacks. Take a look at the CSIS Commission study "Securing Cyberspace for the 44th Presidency". It speaks of major intrusions at many governmental agencies, from DoD, to DHS, to Commerce and the State Department.

Creating a new and massive repository of private data, without first examining all of the central and connecting networks and systems, would immediately put all of that data at risk, and provide even more profit on an attacker's original investment in cracking and then eavesdropping on those systems.

Before any centralized system of this scale is created, we need to drain the swamps.

Are We Looking at an ID Theft Stimulus Package?

2009-02-11T21:40:00.000-08:00

Thanks to an article by Betsy McCaughey, published on the Bloomberg.com news site (here) yesterday, I got an eyeful about the new economic stimulus plan's efforts to create a new and centralized operation to monitor and aggregate data around our individual health records. Focused around the creation of the "Office of the National Coordinator for Health Information Technology", this new initiative seeks to require that the medical records and insurance information of US residents be provided to and through the new federal office, through the "utilization of an electronic health record for each person in the United States by 2014" (The package is here, the detail is in Section 3001.c.3.A.ii ).

While Ms. McCaughey's article centers on the Washington machinations behind the introduction of this new federal health care initiative, I'm much more focused on the security implications. Whether the records arrive from red state or blue state, or whether I am (R), (D), (I), or (Other), the theft of my health care records, my identification, and that of my family, is going to make me pretty upset.

Given the state of health care records management systems, the existing insecurity in many of the institutions that will handle this information, and the increasing incidence and impact of medical identity theft, I think it very likely that this plan could be a disaster.

The threats to medical records are very clear, and very pressing. In a January 15, 2009 report from HHS on the topic of medical identity theft, (here), it is clear that the threats from well-organized and motivated parties are increasing, along with their impacts. An earlier report, in 2006, from the World Privacy Forum (here) provides detailed examination of the dangers, which range from financial loss, to denial of insurance, to actual physical harm. And in California, famous for CA 1386 which led to new transparency in data breaches, AB 1298 has been in force for a year, and calls for expansion of those protections to medical records (here).

Much of the problem is born out of the remarkable complexity of these multi-layer, multi-organizational, and highly heterogeneous systems. These systems were never meant to speak to one another, and they were certainly not meant to do it over public networks. The introduction of HIPAA in 1996 resulted in some improvement, but much of the effort was related to physical data handling, and did not result in a new form of secure data handling across these widely varying systems. This lack of natural consistency requires that any effort to federate this information sharing take into consideration the existing applications, practices, and processes, that currently facilitates the delivery of quality care, with an eye towards minimizing disruption while creating a secure environment for transfer.

A good analog to this effort exists among the credit card providers. Their standards and best practices for securing data, the Payment Card Industry Data Security Standard (PCI DSS), was initially released in 2004, and has gone through multiple revisions since. In spite of that evolution, and in spite of the natural tendency of financial organizations to lock things down, credit card data theft continues to grow at an alarming rate. Roughly five years after the introduction of these data security standards, the challenge is still clearly beyond the capabilities of the industry. (See credit card losses within ITRC research here. )

Whether it is the loss of data on 45,000 FAA employees, or 30,000 employees at health care provider Kaiser Permanente , we know that the existing systems are not sufficiently secure. Before we look to combining all of that into a new, and highly complicated system that will provide a massive target and limitless venues for attack, we must first stop and think logically about what it will cost, how it can be accomplished, and how long it will really take, to make this system safe.