“Cybersecurity is not very important” is a new paper by the very smart Andrew Odlyzko. I do not agree with everything he says, but it’s worth reading and pondering if and why you disagree with it. I think I agree with it more than I disagree.
I’m pleased to be able to share work that Shostack & Associates and the Cyentia Institute have been doing for the Global Cyber Alliance. In doing this, we created some new threat models for email, and some new statistical analysis of
It shows the 1,046 domains that have successfully activated strong protection with GCA’s DMARC tools will save an estimated $19 million to $66 million dollars from limiting BEC for the year of 2018 alone. These organizations will continue to reap that reward every year in which they maintain the deployment of DMARC. Additional savings will be realized as long as DMARC is deployed.
Twenty years ago, Windows 95 was the most common operating system. Yahoo and Altavista were our gateways to the internet. Steve Jobs just returned to Apple. Google didn’t exist yet. America Online had just launched their Instant Messenger. IPv6 was coming soon. That’s part of the state of software in 1997, twenty years ago. We need to figure out what engineering software looks like for a twenty year lifespan, and part of that will be really doing such engineering, because theory will only take us to the limits of our imaginations.
Today, companies are selling devices that will last twenty years in the home, such as refrigerators and speakers, and making them with network connectivity. That network connectivity is both full internet connectivity, that is, Internet Protocol stacks, and also local network connectivity, such as Bluetooth and Zigbee.
We have very little idea how to make software that can survive as long as AOL IM did. (It’s going away in December, if you missed the story.)
“The customer can choose to acknowledge the policy, or can accept that over time their product may cease to function,” the Sonos spokesperson said, specifically.
Or, as the Consumerist, part of Consumer Reports, puts it in “Sonos Holds Software Updates Hostage If You Don’t Sign New Privacy Agreement:”
There are some real challenges here, both technical and economic. Twenty years ago, we didn’t understand double-free or format string vulnerabilities. Twenty years of software updates aren’t going to be cheap. (I wrote about the economics in “Maintaining & Updating Software.”)
The image at the top is the sole notification that I’ve gotten that Office 2011 is no longer getting security updates. (Sadly, it’s only shown once per computer, or perhaps once per user of the computer.) Microsoft, like all tech companies, will cut functionality that it can’t support, like <"a href="https://www.macworld.com/article/1154785/business/welcomebackvisualbasic.html">Visual Basic for Mac and also “end of lifes” its products. They do so on a published timeline, but it seems wrong to apply that to a refrigerator, end of lifeing your food supply.
There’s probably a clash coming between what’s allowable and what’s economically feasible. If your contract says you can update your device at any time, it still may be beyond “the corners of the contract” to shut it off entirely. Beyond economically challenging, it may not even be technically feasible to update the system. Perhaps the chip is too small, or its power budget too meager, to always connect over TLS4.2, needed addresses the SILLYLOGO attack.
What we need might include:
- A Dead Software Foundation, dedicated to maintaining the software which underlies IoT devices for twenty years. This is not only the Linux kernel, but things like tinybox and openssl. Such a foundation could be funded by organizations shipping IoT devices, or even by governments, concerned about the externalities, what Sean Smith called “the Cyber Love Canal” in The Internet of Risky Things. The Love Canal analogy is apt; in theory, the government cleans up after the firms that polluted are gone. (The practice is far more complex.)
- Model architectures that show how to engineer devices, such as an internet speaker, so that it can effectively be taken offline when the time comes. (There’s work in the mobile app space on making apps work offline, which is related, but carries the expectation that the app will eventually reconnect.)
- Conceptualization of the legal limits of what you can sign away in the fine print. (This may be everything; between severability and arbitration clauses, the courts have let contract law tilt very far towards the contract authors, but Congress did step in to write the Consumer Review Fairness Act.) The FTC has commented on issues of device longevity, but not (afaik) on limits of contracts.
What else do we need to build software that survives for twenty years?
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.
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.
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.
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.
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.
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.)
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