“Put all your eggs in one basket and then watch that basket.” — Andrew Carnegie
Many people take Carnegie’s advice to heart when it comes to security. They anchor almost all of their security with a single vendor, and the vendor is more than happy to oblige. Most infosec vendors seem incapable of designing security architectures that don’t put their products at the root of all trust. “Just give us your keys,” they say, “and we’ll take care of the rest.”
It’s not just that this is the easiest architecture to design, it’s also to the vendor’s benefit if their customers are fully dependent on them. When you outsource all security decisions and trust, both the individual consumer and the enterprise are incapable of protecting themselves in the face of threats. When inevitably there’s a hole in the vendor’s basket and eggs start to break, the customer discovers just how powerless they are to do anything about it. Often they even find it challenging to get information about the size of the hole and whether their eggs are affected.
We live in an increasingly interconnected and interdependent society. Many people have realized over the past few years just how dependent they have been on outsourced infrastructure and supplies, and how unnerving it can be when those things are disrupted. In response, a number of people have changed their focus toward more self-sufficiency.
While there are exceptions, few people focused on self-sufficiency want to be completely off-grid with no dependence on society. Instead, people see the risk of being fully dependent upon others for all their needs, and realize they need more balance. This balanced approach means reducing, not necessarily eliminating, ones dependence on others. Instead of disconnecting from the public electric grid, you may install solar panels and backup batteries for when the power goes out. Instead of becoming a farmer or a chef, you may grow more of your vegetables in your own garden and cook more meals at home. Instead of making everything from scratch, you may find local sources for important goods, and learn how to repair things yourself.
We need a similar movement toward security self-sufficiency. Like with the larger self-sufficiency movement, this doesn’t mean eliminating all dependence on others. Instead it means reducing that dependence and increasing your own ability to manage your security. It means moving some of your eggs into your own basket.
Many security organizations take part in so-called “tabletop exercises” where they game out potential security incidents ahead of time. These kind of thought experiments can be very valuable as a way to identify gaps in your plans and holes in your defense. They can also be a valuable way to identify your dependence on outside vendors. Gaming out what happens if one of your vendors has an extended outage, or a breach, will help expose the level of dependence your business has on them.
For instance, if you use a third party for single sign-on, what happens if they suffer an outage? Will you still be able to login to your systems? If they get breached, will their attackers have access to your systems? If you rely on a vendor’s signing keys to validate the integrity of your software, what happens if that key gets compromised? What if an attacker adds a back door to third party software you depend on?
Security expert Moxie Marlinspike coined the phrase “trust agility” to refer to ones ability to revoke trust from a third party. It was originally used in the context of a series of Certificate Authority (CA) breaches that allowed the attackers to create valid certificates for major corporations. Because web browsers trusted all CAs implicitly and equally, and that trust was built into the browser binary itself, at the time there was little recourse (and limited trust agility) if a CA’s keys were compromised.
While a number of practices such as certificate pinning came into use to respond to the risk of compromised CAs, the idea of trust agility extends beyond the CA system. How easily could you revoke trust in a vendor if they had a breach? How easily could you switch to a new vendor? The lower a vendor’s trust agility, the greater your dependence, and your risk.
Imagine not having the keys to your own house. OK so maybe that isn’t as far-fetched as it used to be in a world of cloud-connected “smart locks”. In fact, I once worked at an office that used a smart lock. None of the employees had office keys, instead we used an app on our phone to get into the office in the morning and to re-enter the office whenever we left for lunch or to use the restroom. One day our Internet connection dropped, which we discovered when we found ourselves locked out! Thankfully there still was a physical key lock on the door, however only two executives in the company held those keys so they had to let the rest of the employees in. Instead of play doorman the rest of the day, they just propped the door open until the Internet connection could get restored.
Many enterprises and consumers find themselves in this same situation or worse when they hand their keys to a third party. These may be keys to access systems, they may take the form of signing keys used to detect tampering in software, or they may even be encryption keys used to protect data. In any case, because these systems were designed to depend on vendor keys, when that vendor has a problem the customer is left with waiting for the issue to be resolved, or bypassing the security altogether–the equivalent of propping the door open.
You should hold the keys to your systems. This is why when we wanted to secure our boot process, we ultimately rejected conventional approaches and instead developed PureBoot, which secures the boot process using keys under your control. While systems that add the PureBoot Bundle start with Purism-generated keys, one of the first things we recommend customers do after they get their computer is reset all of those keys to something fully under their control.
Part of security self-sufficiency is being able to audit your digital supply chain. You should be able to inspect software you rely on, especially software you depend on for security, for backdoors or security bugs. Even if you don’t personally have the expertise to perform an audit, you should be able to hire an expert to do it on your behalf. If you or someone else finds a security bug, you shouldn’t be subject to a vendor’s timelines to patch if you have the ability to do it yourself.
We take a number of steps to secure our digital supply chain, and document many of them in this post. Because we aim to use free software whenever possible in our platform, from software to firmware, all of the code is freely available to audit at any point. This also means that if you find a security bug in software you rely on, you aren’t completely dependent on Purism or any other vendor to patch it. You always have the option to take matters in your own hands.
In the end, it’s just not wise to keep all of your security eggs in one basket. Security self-sufficiency means identifying those areas where you are dependent upon other companies, and choosing solutions that allow you to revoke trust easily, hold your own keys, and audit your digital supply chain.
|Librem Mini||In Stock||10 days|
|Librem Servers||Out of Stock||--|
|Librem Key||In Stock||10 days|
|Librem 14||In Stock||10 days|
|Librem 5 USA||In Stock||10 days|
|Librem 5||Currently shipping backlogs||52 weeks|