Enterprise encryption and cybersecurity first principles.

Rick Howard: Hey everyone. Hey everyone. We are back. We're back.

Rick Howard: Welcome back to Season Six of the CyberWire's CSO Perspectives podcast. 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 really sure what it was going to be about, but four topics in, I decided that instead of covering some random cybersecurity issues that just happened to present themselves, I would get back to basics and organize around my favorite pet peeve topic, first principles. After all, I haven't been writing and speaking about the idea for several years, but not any consistent way. 

Rick Howard: For the series, if you recall, I've 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 barbecue pit in your backyard. You can't place the next row of bricks until you have established the row directly under it.

Rick Howard: The foundation provides the strength for the first row of bricks. The foundation and the first row convey the strength to the second row and so on. But before I go too much further, though, I gotta confess. 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 way 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 they kind of sneer at me wearing my apron while I'm doing the dishes as they head downstairs to confer with my wife in her basement workshop.

Rick Howard: But I'm fine with that. I've made my peace with that. And by the way, 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 got. And so let's recap.

Rick Howard: 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.

Rick Howard: That's it. That's the absolute infosec first principle for any organization, no matter what 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, this stone that gives our entire infosec wall strength, I laid the following bricks on top of that foundation over the next few seasons, zero trust and intrusion kill chain prevention, security operation centers, DevSecOps and SOAR, incident response, cyber threat intelligence, identity management, red team and blue team operations, resilience, data loss protection, and risk forecasting.

Rick Howard: As I began working on this next Season Six, 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 barbecue 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're going to pull a Tim the Tool Man and try to fix it. Oh no. And we're going to start by strengthening the resilience section of the wall by adding encryption.

Rick Howard: My name is Rick Howard. You are listening to CSO Perspectives, my podcast about the ideas, strategies, and technologies that senior security executives wrestle with on a daily basis.

Rick Howard: 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. 

Rick Howard: 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 that the CyberWire collects or generates. I'm only worrying about the data that if they were destroyed or stolen would impact us materially.

Rick Howard: From the resilience episode, I quoted the Datamaran website's definition, "materiality is 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 on the form of ransomware and everything in between.

Rick Howard: I will talk about strategies to address data destruction in an upcoming episode this season. For this show though, we are talking about how to protect against data theft as a backyard barbecue brick that sits on the data loss protection side of the wall. In Season Two, Episodes Five and Six, I covered data loss protection frameworks from the U S 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.

Rick Howard: 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. So in a nod to one of my favorite superhero movies of all time, "Spider-Man Into the Spider-Verse," when all the multidimensional Spider-People take turns explaining their origin story by saying, "all right, let's do this one last time. My name is Peter Parker. I was bitten by a radioactive spider and for 10 years, I've been the one and only Spider-Man. I'm pretty sure you know the rest." 

Rick Howard: Let's do this one more time for cryptography. Cryptography is the art and science of code making. Encryption converts plain text into an unrecognizable form using the codes that cryptographers make. Signing users trapped door or mathematical one-way functions from cryptography or non-repudiation. In other words, signed message or file authors can't deny they signed it and it's mathematically impossible for a third party to forge a signature. Keys are a string of characters use within the cryptographic function to transform plain text into cipher text or back. Like a physical key, they lock 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. 

Rick Howard: As an aside, for the computer gamers out there, if you think you might like to try your hand at cryptology, there was a lovely little first person computer game called Cypher, spelled C Y P H E R, where you walk through a museum of cryptology and solve the multiple puzzles provided in various forms of cryptanalysis, like steganography, transposition, monoalphabetic  substitution, polyalphabetic substitution, mechanized cryptography, and digital cryptography. I got as far as the first puzzle before I got stumped, but hey, this might be your thing. 

Rick Howard: But this 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 their Spartan friends to decode the messages on the other side, they needed an identical scytale in terms of width and length. 

Rick Howard: By 60 BC, the Romans used a simple substitution cipher where they encoded messages by shifting the letter by some agreed upon number. Like for example, if the number was three, the plain text of the letter A becomes an encoded letter D, the plain text B becomes an encoded E, and so forth.

Rick Howard: 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 electromechanical machine in which the key was embedded on a rotating disc. The next year in 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 World War I and World War II.

Rick Howard: By the 1970s, IBM invented a block cipher. 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 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.

Rick Howard: 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's just sitting there for some future purpose. Data in motion is data 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 dataset. 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 where they get you.

Rick Howard: After you think about it for more than two seconds, you realize that the permutations for all the things that have to be signed and encrypted grow exponentially. I've mentioned in the CSO Perspectives series many times all the different islands where we store data: laptops, cell phones, data centers, SaaS services, and hybrid  cloud services.

Rick Howard: For every physical device that touches those data islands, for every workload that operates in the cloud environment, for every person who uses those devices and workloads, and for every transaction between people and technology, there is a potential for some kind of cryptographic transformation. 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. 

Rick Howard: The unremitting volume and pace of these essential digital operations is it enough to make any security executive curl up into a fetal position in the SOC murmuring to themselves, "I hope it all works. I hope it all works." 

Rick Howard: Gartner’s David Mahdi and Brian Lowans in the paper they wrote in 2020, said that security executives struggle to understand the capabilities and limitations that encryption key management 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.

Rick Howard: 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 the data islands with all of those permutations is still intricate, knotty, and dare I say, labyrinthine?

Rick Howard: 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 homegrown 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.

Rick Howard: 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," that's Fenn's label, as consumers realize the potential of the new idea. From there, expectations begin to diminish through the "trough of disillusion." As the same people begin to realize that the new tech is not quite ready for prime time. From there, expectations arise again, through a much gentler "slope of enlightenment." And finally, once the product has matured reaches the "plateau of productivity." I say all of that because according to Gartner's Mahdi and Lowans, enterprise key management is currently on the slope of enlightenment, but it's five to 10 years away from the plateau of productivity. A subtle point here is that whatever systems and processing you are using to encrypt your organization's material data, those systems and processes by definition become material in a recursive kind of way.

Rick Howard: You use the encryption system to protect your sensitive data, but because the encryption system is critical to the business process, it's 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 backdoor 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 back door 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 move 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 gave them legitimate access to cloud resources.

Rick Howard: 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. For zero trust, we will want to centralize our key management operations. Don't leave this process in the hands of the individual teams that need it. It will never be their first priority. You will also want to limit the number of administrator accounts that can generate keys to the absolute minimum, and then watch those accounts like a hawk. And finally, you might consider adding quorum authorization. In other words, you don't just use one account to authorize key generation, you use several. For the intrusion kill chain prevention strategy, the MITRE ATT&CK framework describes the weak encryption technique ID T1600 as adversary groups compromising "a network device's encryption capability in order to bypass encryption that would otherwise protect data communications."

Rick Howard: Apt32, a Vietnamese state sponsored adversary group, and UNC2452 are at least two teams that use this technique. Blocking these two groups entire attack sequence across the intrusion kill chain and any other adversary group that uses this technique for all known campaigns would be prudent.

Rick Howard: For 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. For risk forecasting, include in your model, a way to account for deploying your first principle strategies against the encryption system.

Rick Howard: 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? Model the same step-by-step process for the intrusion kill chain strategy and the resilience strategy.

Rick Howard: Be sure to weigh the cost of each step as you go to see if it's justified against the risk appetite of your board and senior leaders. You may be asking yourself, does encryption provide protection against ransomware? Well, maybe. At least some pieces of it. Your encryption program might make it difficult for the adversary to find the important data to hold hostage. But that's not likely. 

Rick Howard: Ransomware group common practice is to just encrypt everything. They're 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 then they can also simply sell the data whether you paid them or not.

Rick Howard: In that regard, encryption might allow you to prevent data loss like customer personally identifiable information, or PII, proprietary intellectual property, or IP, and other sensitive information that might be material to the organization if it was made public. 

Rick Howard: One last thing, code signing is a material process. It allows you to guarantee to your customers that the software you are delivering to them actually came from you and not for 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 official 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 did for all of our other material processes and data to include encryption.

Rick Howard: As we place our encryption brick onto our first principle barbecue 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.

Rick Howard: And that's a wrap. Next week, we are inviting our subject matter experts to the Hash Table to see how they do encryption for their organizations. You don't want to miss that. But for this episode, as always, if you agree or disagree with anything I've said, hit me up on LinkedIn or Twitter and we can continue the conversation there.

Rick Howard: The CyberWire's CSO Perspectives is edited by John Petrik and executive produced by Peter Kilpe. Our theme song is by Blue Dot Sessions, remixed by the insanely talented Elliott Peltzman, who also does the show's mixing, sound design, and original score. And I am Rick Howard. Thanks for listening.