Encryption as a cybersecurity first principle.

I’ve been with The Cyberwire now for well over a year. When we started this CSO Perspectives series of essays and podcasts, I wasn’t sure what it was going to be about. But four topics in, I decided that instead of covering random cybersecurity issues that happened to present themselves, I would get back to basics and organize around my favorite pet peeve topic: First Principles. After all, I had been writing and speaking about the idea for several years, but not in any consistent way. 

For the series, If you recall, I have been trying to use the construction of a brick wall as a metaphor to convey the idea that once you know what the foundation is, the next bricks you put on the wall will logically follow. Like building a BBQ pit in your backyard, you can’t place the next row of bricks until you have established the row directly under it. The foundation provides the strength to the first row of bricks. The foundation and the first row of bricks convey the strength for the second row, and so on.

Before I go too much further, though, I have to confess that I have no man-skills in the useful arts. If something needs to be fixed at the Howard house, I turn to my wife. She is more handy than over 90% of the neighborhood tool jockeys. When they need a tool and knock on our door to borrow something, they don’t ask for me. They ask for my wife and kind of sneer at me wearing my apron and doing the dishes as they head downstairs to confer with my wife in her basement workshop. But I’m fine with that. I have made my peace with that. And I’m a damn good dishwasher too.

The point is that I’m the last guy who should be using a building metaphor to convey a complex idea about cybersecurity first principles. Alas, that’s what you have, and so, let’s recap.

Our foundation stone for the entire construction project is this: Reduce the probability of material impact to our organization due to some cyber event in the next few years. That’s it. That’s the absolute infosec first principle for any organization, no matter its size or the resources it has to accomplish the task. I did an entire set of essays and podcasts back in season one that walks us through the thinking on that one. If you need to go back and review, feel free. But given this foundation stone, the stone that gives our entire infosec wall strength, I laid these bricks on top of that foundation over the next few seasons:

• Zero Trust / Intrusion Kill Chain Prevention
• Security Operations Centers
• DevSecOps / SOAR
• Incident Response
• Cyber Threat Intelligence
• Identity Management
• Red Team / Blue Team Operations
• Resilience
• Data Loss Protection
• Risk Forecasting

As I began working on this next season six schedule, I realized that I have some holes in my wall, bricks that I skipped over to work on other parts. And if this was my backyard BBQ pit at the house, sure as anything, it would have fallen over by now. Because, as I have said, I have no man-skills. For this season and next, we are going to pull a Tim the Toolman and try to fix it. And we’re going to start by strengthening the resilience section by adding encryption.

Resilience.

From Season One, Episode Nine, I stole my favorite resilience definition from two Stockholm University researchers, Janis Stirna and Jelena Zdravkovic. They defined it as 

“ ... the ability to continuously deliver the intended outcome despite adverse cyber events.”

That’s a simple sentence but it conveys a lot. The implications are enormous for the IT and infosec teams. No matter what catastrophe occurs, resilience means that my organization continues to deliver whatever it delivers. In the case of The Cyberwire, we publish podcasts. Even if David Bittner, the host of the Cyberwire’s Daily Podcast, accidentally sets his recording studio on fire, the Cyberwire is still going to publish his show somehow. The process of getting it done might be ugly, but we’re going to do it. That’s resilience.

In today’s world though, a good portion of any organization’s resilience plan has to include protecting the data it needs to operate on a daily basis, and any data it stores for historical reasons or for later processing. In that regard, there are only two broad categories to worry about that might have a material impact: data destruction and data theft. 

To be clear, I’m not worried about all the data The Cyberwire collects or generates. I’m only worrying about the data that, if they were destroyed or stolen, would impact us materially. From the resilience episode, I quoted the Datamaran website’s definition:

“Materiality: Any major impact on the financial, economic, reputational, and legal aspects of a company, as well as on the system of internal and external stakeholders of that company.”

Data destruction can be anything from unintentional hard drive failure to systematic nation state cyber attacks in the form of ransomware and everything in between. I will talk about strategies to address data destruction in an upcoming essay this season. For this essay, we are talking about how to protect against data theft as a Backyard BBQ brick that sits on the data loss protection brick.

In season 2, episodes five and six, I covered data loss protection frameworks from the US government and the commercial sector. I made the argument though that most of those ideas would be covered by any robust zero trust program. The frameworks are interesting but not that useful. In the episode, I made the case that the single most useful thing anyone could do to reduce the probability of your data getting stolen, is to encrypt it. Which brings us to the galaxy of cryptography.

History: cryptography, encryption, cryptology, signing and cryptanalysis.

Every time I revisit this subject, I always feel like I have to relearn the definitions again. My senior moment brain can’t seem to keep them all straight. In a nod to one of my favorite superhero movies of all time, “Spiderman into the Spiderverse,” when all the multidimensional spider people take turns explaining their origin story by saying, “All right, let's do this one last time,” let's do this one more time for Cryptography.

• Cryptography, pronounced like photography, is the art and science of code making.
• Encryption converts plain text into an unrecognizable form using the codes that the cryptographers make. 
• Signing uses trapdoor or mathematical one-way functions from cryptography for non-repudiation. In other words, signed message or file authors can’t deny that they signed it, and it’s mathematically impossible for a third-party to forge a signature.
• Keys: a string of characters used within a cryptographic function to transform plain text into cipher text, or back. Like a physical key, it locks data so that only someone with the right key can unlock it.
• Cryptanalysis is the reverse of Cryptography. It’s all the things you do to break the codes.
• And just to make things more confusing, cryptology captures both disciplines: cryptography and cryptanalysis. 

As an aside, for the computer gamers out there, if you think you might like to try your hand at cryptology, there is a lovely little first person computer game called “CYpHER” where you walk through a museum of cryptology and solve the multiple puzzles provided in various forms of cryptanalysis: 

• Steganography
• Transposition
• Mono alphabetic Substitution
• Poly alphabetic Substitution
• Mechanised Cryptography
• Digital Cryptography

I got as far as the first puzzle before I got stumped, but hey, this might be your thing.The cryptography idea has been around since the world was young. According to the Thales Group, the Spartans around 600 BC, used a device called a scytale to code plain text into encrypted messages. In order for the Spartan friends to decode the messages on the other side, they needed an identical scytale in terms of width and length. By 60 BC, the Romans used a simple substitution cipher where they encoded messages by shifting the letter by some agreed upon number. For example, if the number was 3, the plain text of the letter A becomes an encoded letter D, the plain text B becomes an encoded E, and so forth. Fast forward to 1553, Giovan Battista Bellaso introduced the idea of a secret key or password that two parties would need to encrypt and decrypt messages. 

By 1917, An American named Edward Hebern had invented an electro-mechanical machine in which the key was embedded in a rotating disc. The next year, 1918, German engineer Arthur Scherbius invented the Enigma machine using more than one rotor, and the German military adopted it to send coded transmissions during WWI and WWII. By the 1970s, IBM invented a block cypher. Instead of using multiple letters as the enigma rotors did, the key is an entire block of text. The US Government adopted the IBM Data Encryption Standard or DES in 1976, and used it until it was broken in 1997. In 1976, Whitfield Diffie and Martin Hellman created the Diffie-Hellman key exchange, making it possible to send encrypted messages without having to share a secret key beforehand and to also to sign messages and files so that the user can verify if they are legitimate. By 2000, the Advanced Encryption Standard or AES replaced DES as the standard by being faster and having the ability to use much longer keys.

Common encryption uses.

We use encryption in two ways: for Data-at-rest and for data-in-motion. Data-at-rest is stored on some hard drive somewhere. Nobody is moving it and nobody is processing it. It is just sitting there for some future purpose. Data-in-motion is being moved between point A and point B, as it is when a website delivers content to a user, or an email message travels from sender to receiver. It’s also when we are processing it somehow like when we search through a database or when we are running machine learning algorithms on a data set.

When you say it like that, it makes complete sense that you would encrypt both data-at-rest and data-in-motion. How hard could it be? But that’s how they get you. After you think about it for more than two seconds, you realize that the permutations for all of the things that have to be signed and encrypted grow exponentially.

I’ve mentioned in this CSO Perspectives series many times all the different islands where we store data: laptops, cell phones, data centers, SaaS services, and hybrid cloud services. For every physical device that touches those data islands, for every workload that operates in a cloud environment, for every person who uses those devices and workloads, and for every transaction between people and technology, there is potential for some kind of cryptographic transformation. 

Encryption challenges.

When I say cryptographic transformation, that means that somewhere in the process, some algorithm is generating a key, applying a key, saving a key, using a key, changing a key, or decommissioning a key for every transaction, every device and every person across all of your data islands. The unremitting volume and pace of these essential digital operations is enough to make security executives curl up into a fetal position in the SOC murmuring to themselves, “I hope it all works. I hope it all works.” Gartner’s David Mahdi and Brian Lowans, in a paper they wrote in 2020, said that security executives “struggle to understand the capabilities and limitations that encryption key management (EKM) solutions provide, and how to properly configure them.” They implied that most of us don’t have a comprehensive encryption policy nor a global plan. They speculated that at best, our approaches are piecemeal and on a case by case basis as opportunities arise. They noticed that in most cases, the encryption process and policy are not organizational imperatives.

The good news is that we can reduce the problem size by only dealing with material data. Unfortunately, that doesn’t reduce the complexity. Orchestrating encryption solutions for your material data across all of those data islands with all of those permutations is still intricate, knotty, and dare I say, labyrinthine? The scary part is that most of us have been trying to do it ourselves, manually. And because of the diverse array of data silos across all of the data islands, investment in multiple encryption products is required. We design our own home-grown software tools using collections of open source and commercial software like OpenZFS, LUKS, VeraCrypt, or BitLocker or tying into some of the cloud key management SaaS services from the likes of Google, Microsoft, and AWS. There hasn’t been any sort of comprehensive encryption platform that works across all data islands. But that soon may be changing.

The Gartner Hype Cycle and encryption.

According to the Challenging Coder website, Gartner’s Jackie Fenn created the concept of the Hype Cycle in 1995. She noticed a repeated pattern of expectation attitudes from consumers of tech and security products as new and innovative products emerged in the marketplace. The anticipation starts with a product announcement, and then rises through to the “peak of inflated expectations” as consumers realize the potential of the new idea. From there, expectations begin to diminish through the “trough of disillusionment” as these same people begin to realize that the new tech is not quite ready for prime time. From there, expectation rises again through a much gentler “slope of enlightenment” and finally, once the product has matured, reaches the “plateau of productivity.” According to Mahdi and Lowans, Enterprise Key Management is on the slope of Enlightenment but 5-10 years away from the plateau of productivity.

Encryption and first principles

A subtle point here is that, whatever systems and processes you are using to encrypt your organization’s data, those systems and processes by definition become material in a recursive kind of way. You use the encryption system to protect your sensitive data, but because the encryption system is critical to the process, it is also material to the organization. If a bad guy compromises your encryption system in some way, then everything you're trying to protect with it is compromised.

A case in point is the Solarwinds back door attack that started in December of 2020. It’s probably the most famous supply chain attack in recent memory, but the damage to its victims didn’t come from the injected backdoor of the Solarwinds platform. That was just the adversary group (UNC2452) establishing the beachhead on the intrusion kill chain attack sequence for some 18,000 victims. The damages came later for roughly 40 victims as UNC2452 moved laterally within their networks looking for administrator credentials. For some victims, UNC2452 compromised the cloud token authorization process that allowed UNC2452 to generate keys that give them legitimate access to cloud resources.

In case you're keeping score at home, that’s bad.

As such, reducing the probability of this kind of attack against your encryption system is accomplished by following the same first principle strategies that we use to protect our other material assets.

Zero Trust

• Centralized key management. Don’t leave this process in the hands of the individual teams that need it. It will never be their first priority.
• Limit the number of administrator accounts that can generate keys to the absolute minimum.
• Watch those accounts like a hawk.
• Add quorum authorization; i.e, not just one account required to authorize key generation, but several.

Intrusion Chain Prevention

• The MITRE ATT&CK framework describes the “Weak Encryption (ID T1600)” technique as adversary groups compromising “a network device’s encryption capability in order to bypass encryption that would otherwise protect data communications.”
• APT32, a Vietnamese state sponsored adversary group, and UNC2452 are at least two teams that use this technique. Blocking these two group’s entire attack sequence across the intrusion kill chain, and any other adversary group that uses the technique, for all known campaigns would be prudent.

Resilience

• A fully deployed encryption system is the plumbing for delivering the must-have “magic” that your customers demand. If the plumbing fails, you can’t deliver the magic.
• Design the encryption system to survive a catastrophic failure in the same way you have already designed the resilient system for delivering the magic. 

Risk Forecasting

• Include in your model a way to account for deploying your first principle strategies against the encryption system
• Your probability of material impact should go down for each step that you deploy. In other words, what’s the probability without any safeguards? What’s the probability of a partially deployed zero trust program? What’s the probability of a fully deployed zero trust program? Incorporate this same step by step process for the intrusion kill chain strategy and the resilience strategy.
• Be sure to weigh the cost of each step as you go to see if it is justified against the risk culture of your board and your senior leaders.

Does encryption provide protection against ransomware?

Maybe.

Your encryption program might make it difficult for the adversary to find the important data to hold hostage, but that’s not likely. Ransomware group common practice is to just encrypt everything. They are not looking for something specific to cause you trouble. They cast a wide net.

Interestingly, the common way ransomware groups hold your data hostage is by encrypting those data with their own keys. Even if your data are encrypted, the ransomware groups just add another layer of encryption over the top of it. They can’t read it, but neither can you. 

If your data aren’t encrypted, then the ransomware group has another revenue opportunity. They can ask for money to deliver the key so that you can unencrypt your data. Then they can ask for money not to make the data public. And they can also simply sell the data, whether you've paid them or not. In that regard, Encryption might allow you to prevent data loss like customer Personally Identifiable Information (PII), proprietary intellectual property (IP), and other sensitive information that might be material to the organization if it was made public. 

Code signing is a material process.

Code signing allows you to guarantee to your customers that the software you are delivering to them actually came from you and not from some other third party. That’s good practice. Unfortunately, it's not foolproof. As we saw in the UNC2452 attack campaign, Solarwinds did sign their code but since the adversary group compromised their supply chain process, the UNC2452 installed backdoor got the signature too. We can reduce the probability of that happening for your own organization by considering the code-signing process as material, and protecting it with the same first-principle strategies as we do all of our other material processes and data, to include encryption.

The first principle BBQ pit.

As we place our encryption brick onto our first-principle BBQ pit, it sits on top of our resilience side of the wall. By doing this, we start to fill in the structure alongside the zero trust and intrusion kill chain sides. The next hole we will fill will be the backup strategy. That will be the next essay. Stay tuned.

Reading list.

S1E6: 11 MAY: Cybersecurity First Principles

S1E9: 01 JUN: Cybersecurity first principles - resilience

S2E5: 17 AUG: Data loss protection: a first principle idea.

S2E6: 24 AUG: Data loss protection: around the Hash Table.

“12 Types of Cryptographic Key.” by Spacey, John. Simplicable. 2016. 

“Bombshell Report Finds Phone Network Encryption Was Deliberately Weakened.” by By Lorenzo Franceschi-Bicchierai, Vice.com. 2021.

"Code Girls: The Untold Story of the American Women Code Breakers Who Helped Win World War II," by Liza Mundy, Narrated by Erin Bennett, Published by Hachette Books, 10 October 2017.

"Cyber Resilience – Fundamentals for a Definition,” by Fredrik Björck, Martin Henkel, Stockholm University, Janis Stirna, Jelena Zdravkovic, Stockholm University, Article in Advances in Intelligent Systems and Computing, January 2015, last visited 30 April 2020

“Develop an Enterprise Wide Encryption Key Management Strategy or Lose the Data,” By David Mahdi, Brian Lowans, Gartner, 29 September 2020.

“EKMF - Enterprise Key Management System.” Ibm.com. 2020. 

“Encryption and Signing | Encryption Consulting.” by Puneet, Encryption Consulting, 23 September 2020. 

“Encryption (Noun).” Word Notes Podcast, The CyberWire. June 8, 2021. 

“Here Are 24 Reported Victims of the SolarWinds Hack (so Far) - PanaTimes.” 2021. PanaTimes. 2021. 

“How to Build a Brick Barbecue.” by Silverline Tools, YouTube Video 2016.

“Materiality in a nutshell,” by Datamaran, last visited 27 June 2021.

“MITRE ATT&CK®.” Mitre.org. 2021. 

“Recommendation for Key Management: Part 1 – General: NIST Special Publication 800-57 Part 1

Revision 5,” by Elaine Barker, NIST, May 2020.

“The Evolution of Cryptographic Algorithms.” 2021. Ericsson.com. 2021. 

“What Are Cryptographic Signatures? Complete Beginner’s Guide.” by “Curran, Brian, Blockonomi 2019.

“What Is a Cryptographic Key? | Keys and SSL Encryption.” 2021. Cloudflare. 2021. 

“Why Enterprise Encryption Solutions Have a Long Way to Go.” 2015. Virtru. 14 October 2015.