Maintaining & Updating Software

In the aftermath of Wannacry, there’s a lot of discussion of organizations not updating their systems. There are two main reasons organizations don’t update the operating systems they run: compatibility and training. Training is simpler — you have to train people about the changes to the Start Menu to move them to Windows 8, and that’s expensive. (I sometimes worked with sales people when I was at Microsoft, and they could have managed this much better than they have.)

Compatability is harder. In his excellent blog post on “Who Pays?,” Steve Bellovin discusses how “achieving a significant improvement in a product’s security generally requires a new architecture and a lot of changed code. It’s not a patch, it’s a new release.” There are substantial changes to the ways memory is managed and laid out between the versions, including ASLR, DEP, CFG, etc. There are many changes and seeing how they impact real programs is hard. That’s part of the reason Microsoft released the Enhanced Mitigation Experiment Experience Toolkit.

Rusting car

This doesn’t just apply to platforms, it also applies to libraries. (For example, see Jon Callas, “Apple and OpenSSL.”

Even when compatibility is generally very high, someone needs to test the code to see if it works, and that costs money. It costs a lot more money if you don’t have test code, test documentation (YAGNI!) or if, umm, your test code has dependencies on libraries that don’t work on the new platform…It is unlikely that re-certifying on a new platform is less than weeks of work, and for larger products, it could easily extend to person years of work, to maintain software that’s already been sold. The costs are non-trivial, which brings me back to Steve Bellovin’s post:

There are, then, four basic choices. We can demand that vendors pay, even many years after the software has shipped. We can set up some sort of insurance system, whether run by the government or by the private sector. We can pay out of general revenues. If none of those work, we’ll pay, as a society, for security failures.

This is a fair summary, and I want to add two points.

First, it remains fashionable to bash Microsoft for all the world’s security woes, there is a far bigger problem, that of open source, which is usually released without any maintenance plan. (My friends at the Core Infrastructure Initiative are working on this problem.)

  • Code is speech. The United States rarely imposes liabilities on people for speaking, and it seems downright perverse to do so more if they let others use their words.
  • There may not be an organization, or the author of the code may have explicitly disclaimed that they’re responsible. If there is, and we as a society suddenly impose unexpected costs on them, that might inhibit future funding of open source. (As an example, the author of Postfix was paid by IBM for a while. Does IBM have responsibility for Postfix, now that he’s left and gone to Google?) How does the “releasing code” calculus change if you’re required to maintain it for ever?
  • The Open Source Definition prohibits discrimination against fields of endeavor, and requires licenses be technology neutral. So it seems hard to release an open source library and forbid the use of code in long-lived consumer goods.
  • What if Bob makes a change to Alice’s code, and introduces a security bug in a subtle way? What if Alice didn’t document that the code was managing a security issue? Does she need to fix it?

Second, the costs to society will not be evenly distributed: they’re going to fall on sectors with less software acumen, and places where products are repaired more than they’re replaced, which tend to be the poorer places and countries.

[Update: Ross Anderson blogs about a new paper that he wrote with Éireann Leverett and Richard Clayton. The paper is more focused on the regulatory challenge that maintaining and updating software provokes than the economics.]

Photo by Pawel Kadysz.

More Satellites Than You Can Shake a Stick At

This video is really amazingly inspiring:

Not only does it show more satellites than I’ve ever seen in a single frame of video, but the rocket that took them up was launched by the Indian Space Research Organisation, who managed to launch not only the largest satellite constellation ever, but had room for a few more birds in the launch. It’s an impressive achievement, and it (visually) crystalizes a shift in how we approach space. Also, congratulations to the team at Planet, the ability to image all of Earth’s landmass every day.

Launching a micro satellite into low Earth orbit is now accessible to hobbyists. Many readers of this blog could do it. That’s astounding. Stop and think about that for a moment. Our failure to have exciting follow-on missions after Apollo can obscure the fascinating things which are happening in space, as it gets cheap and almost boring to get to low Earth orbit. The Economist has a good summary. That’s not to say that there aren’t things happening further out. This is the year that contestants in the Google Lunar XPrize competition must launch. Two tourists have paid a deposit to fly around the moon.

But what’s happening close to the planet is where the economic changes will be most visible soon. That’s not to say it’s the only thing to watch, but the same engines will enable more complex and daring missions.

For more on what’s happening in India around space exploration and commercialization, this is a fascinating interview with Susmita Mohanty.

Video link: ISRO PSLV-C37 onboard camera view of 104 satellites deployment

Incentives, Insurance and Root Cause

Over the decade or so since The New School book came out, there’s been a sea change in how we talk about breaches, and how we talk about those who got breached. We agree that understanding what’s going wrong should be a bigger part of how we learn. I’m pleased to have played some part in that movement.

As I consider where we are today, a question that we can’t answer sufficiently is “what’s in it for me?” “Why should I spend time on this?” The benefits may take too long to appear. And so we should ask what we could do about that. In that context, I am very excited to see a proposal from Rob Knake on “Creating a Federally Sponsored Cyber Insurance Program.”

He suggests that a full root cause analysis would be a condition of Federal insurance backstop:

The federally backstopped cyber insurance program should mandate that companies allow full breach investigations, which include on-site gathering of data on why the attack succeeded, to help other companies prevent similar attacks. This function would be similar to that performed by the National Transportation Safety Board (NTSB) for aviation incidents. When an incident occurs, the NTSB establishes the facts of the incident and makes recommendations to prevent similar incidents from occurring. Although regulators typically establish new requirements upon the basis of NTSB recommendations, most air carriers implement recommendations on a voluntary basis. Such a virtuous cycle could happen in cybersecurity if companies covered by a federal cyber insurance program had their incidents investigated by a new NTSB-like entity, which could be run by the private sector and funded by insurance companies.

Journal of Terrorism and Cyber Insurance

At the RMS blog, we learn they are “Launching a New Journal for Terrorism and Cyber Insurance:”

Natural hazard science is commonly studied at college, and to some level in the insurance industry’s further education and training courses. But this is not the case with terrorism risk. Even if insurance professionals learn about terrorism in the course of their daily business, as they move into other positions, their successors may begin with hardly any technical familiarity with terrorism risk. It is not surprising therefore that, even fifteen years after 9/11, knowledge and understanding of terrorism insurance risk modeling across the industry is still relatively low.

There is no shortage of literature on terrorism, but much has a qualitative geopolitical and international relations focus, and little is directly relevant to terrorism insurance underwriting or risk management.

This is particularly exciting as Gordon Woo was recommended to me as the person to read on insurance math in new fields. His Calculating Catastrophe is comprehensive and deep.

It will be interesting to see who they bring aboard to complement the very strong terrorism risk team on the cyber side.

Open Letters to Security Vendors

John Masserini has a set of “open letters to security vendors” on Security Current.

Everyone involved in product or sales at a security startup should read them. John provides insight into what it’s like to be pitched by too many startups, and provides a level of transparency that’s sadly hard to find. Personally, I learned a great deal about what happens when you’re pitched while I was at a large company, and I can vouch for the realities he puts forth. The sooner you understand those realities and incorporate them into your thinking, the more successful we’ll all be.

After meeting with dozens of startups at Black Hat a few weeks ago, I’ve realized that the vast majority of the leaders of these new companies struggle to articulate the value their solutions bring to the enterprise.

Why does John’s advice make us all more successful? Because each organization that follows it moves towards a more efficient state, for themselves and for the folks who they’re pitching.

Getting more efficient means you waste less time per prospect. When you focus on qualified leads who care about the problem you’re working on, you get more sales per unit of time. What’s more, by not wasting the time of those who won’t buy, you free up their time for talking to those who might have something to provide them. (One banker I know said “I could hire someone full-time to reject startup pitches.” Think about what that means for your sales cycle for a moment.)

Go read “An Open Letter to Security Vendors” along with part 2 (why sales takes longer) and part 3 (the technology challenges most startups ignore).

Etsy's Threat Modeling

Gabrielle Gianelli has pulled back the curtain on how Etsy threat modeled a new marketing campaign. (“Threat Modeling for Marketing Campaigns.”)

I’m really happy to see this post, and the approach that they’ve taken:

First, we wanted to make our program sustainable through proactive defenses. When we designed the program we tried to bake in rules to make the program less attractive to attackers. However, we didn’t want these rules to introduce roadblocks in the product that made the program less valuable from users’ perspectives, or financially unsustainable from a business perspective.

Gabrielle apologizes several times for not giving more specifics, eg:

I have to admit upfront, I’m being a little ambiguous about what we’ve actually implemented, but I believe it doesn’t really matter since each situation will differ in the particulars.

I think this is almost exactly right. I could probably tell you about the specifics of the inputs into the machine learning algorithms they’re probably using. Not because I’m under NDA to Etsy (I’m not), but because such specifics have a great deal of commonality. More importantly, and here’s where I differ, I believe you don’t want to know those specifics. Those specifics would be very likely to distract you from going from a model (Etsy’s is a good one) to the specifics of your situation. So I would encourage Etsy to keep blogging like this, and to realize they’re at a great level of abstraction.

So go read Threat Modeling for Marketing Campaigns

What's Copyright, Doc?

I blogged yesterday about all the new works that have entered the public domain as their copyright expired in the United States. If you missed it, that’s because exactly nothing entered the public domain yesterday.

Read more — but only commentary, because there’s no newly free work — at “What Could Have Entered the Public Domain on January 1, 2014?

It’s near-impossible to see how our insanely long copyright terms, or their never-ending extensions encourage Dr. Seuss, Ayn Rand, Jack Kerouac or Ian Fleming to keep producing new work. Those authors have been richly rewarded for their work. But it’s easy to see how keeping those works under copyright reduces creative re-use of our collective cultural heritage.

What Price Privacy, Paying For Apps edition

There’s a new study on what people would pay for privacy in apps. As reported by Techflash:

A study by two University of Colorado Boulder economists, Scott Savage and Donald Waldman, found the average user would pay varying amounts for different kinds of privacy: $4.05 to conceal contact lists, $2.28 to keep their browser history private, $2.12 to eliminate advertising on apps, $1.19 to conceal personal locations, $1.75 to conceal the phone’s ID number and $3.58 to conceal the contents of text messages.

Those numbers seem small, but they’re in the context of app pricing, which is generally a few bucks. If those numbers combine linearly, people being willing to pay up to $10 more for a private version is a very high valuation. (Of course, the numbers will combine in ways that are not strictly rational. Consumers satisfice.

A quick skim of the article leads me to think that they didn’t estimate app maker benefit from these privacy changes. How much does a consumer contact list go for? (And how does that compare to the fines for improperly revealing it?) How much does an app maker make per person whose eyeballs they sell to show ads?

Workshop on the Economics of Information Security

The next Workshop on the Economics of Information Security will be held June 11-12 at Georgetown University, Washington, D.C. Many of the papers look fascinating, including “On the Viability of Using Liability to Incentivise Internet Security”, “A Behavioral Investigation of the FlipIt Game”, and “Are They Actually Any Different? Comparing 3,422 Financial Institutions’ Privacy Practices.”

Not to mention “How Bad Is It? – A Branching Activity Model to Estimate the Impact of Information Security Breaches” previously discussed here.