Data loss protection and cybersecurity first principles.
Rick Howard: Back in the internet dinosaur days - early 2000s - Wikipedia was forming, the dot-com bubble was bursting, the SQL Slammer worm demonstrated to the world the power of exponential network attacks. I was the commander of the U.S. Army's computer emergency response team, and we were having trouble with one particular adversary group who was vacuuming up a lot of unclassified documents scattered across the Army's network. Taking a page from Lance Spitzner and his Honeynet Project and Cliff Stoll and his "Cuckoo's Egg" book, we deployed a small Army web server and loaded it with fake documents that sounded important - you know, enticing documents, documents that might tempt an intruder. We hid in each document a beacon, a small piece of code that would record the IP address of the computer where the document was opened and send it to a secured server that we monitored. In an effort to gain some intelligence about our adversary that we might use to prevent further data loss, we built a rudimentary deception network.
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. This is the 10th show in our series that discusses the development of a general-purpose cybersecurity strategy using the concept of first principles to build a strong and robust infosec program. What I want to determine today is if you deploy the first principle strategies we have discussed in this series, do you even need a data loss prevention program?
Rick Howard: The first concept to consider is that not all data within your organization is material. Let's not waste time and resources worrying about anything that will not affect our first principle atomic vision of what we are trying to do. In fact, I would suggest that most of the data flowing into, out of and through your networks is not material. Now, material data depends on your industry's compliance regulations, the crown jewels to your company's intellectual property, information on mergers and acquisitions and a thousand other things, depending on what your organization does and what your leadership thinks is important. My big SWAG is that, for most organizations, the material information you need to worry about is about 20% of the total. Your results may vary, but the point is that understanding the relative small size of it compared to the complete data set will better enable practical solutions to protect it.
Rick Howard: The second concept to consider is that even if the material data is relatively small in size, it is also likely scattered across multiple data islands - you know, behind the traditional perimeter, like servers, computers, phones and pads, located behind the firewall at the office building; on employee personal and professional mobile devices like laptops, phones and pads in the field and at home; in private data centers; in infrastructure-as-a-service or platform-as-a-service cloud providers' networks - likely both and likely across multiple providers - in SaaS applications that you officially sanction, unofficially tolerate and absolutely forbid; and on physical media like paper, USB drives and portable hard drives. Now, applying first principle thinking across all of the data islands is really hard to do. But if you were to just concentrate on the material data itself, is there something else you can do that will help us prevent material impact to the organization that is, in fact, not just nice to have but fundamental to our overall first principle plan? The industry calls this data loss protection or data loss prevention, depending on the source, and the network defender community is really bad at it.
Rick Howard: As I normally do when I begin to learn about a subject that I'm already supposed to be an expert in, I turn to NIST - the United States National Institute of Standards and Technology. And as near as I can figure, NIST and the United States government have a different name for data loss prevention - they call it controlled unclassified information or CUI. Their official pub for it is 800-171 Revision 2, and they published it in February of 2020. Why is the pub called 800-171? Well, besides governments loving incomprehensible acronyms for any kind of program or common phrase like FIGMO or FUBAR or HMFIC or MOAB, NUB and PFM - and I will let you all discover for yourself the colorful definitions of those acronyms - but governments also love labelling their documents with impenetrable numbering schemes that are only valuable to maybe the authors of the documents and one file clerk buried deep in the basement of the Office of Management and Budget - you know, but I digress.
Rick Howard: The NIST title for the over 100 pages of 800-171 Revision 2 is "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations." Amazingly, they decided they needed a 72-page supplement and published a draft of that in July of 2020. That document is called "Enhanced Security Requirements for Protecting Controlled Unclassified Information." The authors make the text more complicated than it needs to be, but they essentially recommend the same things I have been recommending in this first principle essay series. They don't specifically call out DevSecOps, but they hint at it when they recommend that organizations periodically refresh or upgrade - I'm using air quotes now - "organizational systems and system components to a known state or when developing new systems or components" - end air quotes. And they bury a risk assessment in a laundry list of provisions they call security requirement families. But the basic themes are the same. The point is that for those NIST recommendations that align with your first principle security program, you don't need a specific data loss program - you are already covered.
Rick Howard: But both NIST documents do talk about things that our first principle model hasn't spelled out yet and thus would probably constitute a separate data loss prevention program, like change management, a plan to organize technical changes on systems that host CUI or material data, off-island control, protection for paper, removable digital media and electronic versions as they move out of controlled areas, or destruction, the eradication of paper, removable digital media and electronic versions when they are no longer needed, and labelling, the marking of all CUI or material data written on paper, stored on removable digital media and electronic versions, and, finally, encryption, encoding CUI or material data stored at rest on removable digital media and electronic versions or as it transits.
Rick Howard: All of these strategies have been around the network defender world for a long time. For most organizations, though, they don't get close to implementing all of them. There is not enough bang for your buck, at least in the commercial and academic worlds. In the government space, destruction, off-island control and change management take on a different significance when the information is classified at the highest level. If I was to prioritize for the rest of us, though, encryption would be the thing I tackled first. That has the greatest chance of significantly reducing the probability that you will be materially impacted in the future.
Rick Howard: On the commercial framework side, Forrester developed something they call their Data Control Framework, which matches the NIST framework in terms of data classification or labeling, access control, or zero trust, and data deletion. They have additional components that NIST doesn't include, like data discovering, data intelligence, security data analytics and data inspection. But I think if you build a robust zero-trust program, you already get most of that. What both the NIST documents and the Forrester framework add that I have not seen in any framework document before is the idea of deception or data obfuscation. That is an interesting development.
Rick Howard: Deception networks are not a new idea. Some people call them honeypots. Caleb Townsend of Cybersecurity Magazine claims that the first honeypot was built by Clifford Stoll, made famous in his cybersecurity canon hall-of-fame book "The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage." The bad news is that operating deception networks is resource intensive. You need people to design them and deploy them, and they're not free. You need another set of people to build the fake documents, and this is no small matter either. The documents have to be credible and alluring and not filled with gibberish. The worst part is that you have to be ready to burn it all down at any moment once the bad guys discover it and rebuild it somewhere else with new network names, server names, and new fake documents.
Rick Howard: You have to also understand that building successful deception networks is at least 50% technical savvy and 50% art. The people that do this kind of work are a rare mix of electronic hacker mentality, network engineering, social engineering, and English major. And you all thought that your English degree wouldn't come in handy in your network defender career. Shame on you. If you look at the members of the infamous hacktivist group the Cult of the Dead Cow, you will have some idea of the personality and skills required to pull this off.
Rick Howard: The good news is that if you ever detect activity in your deception network, you absolutely know it is a bad guy because no other employee will legitimately be in there. You can use the telemetry gained in the deception network to ensure the adversary is not in your real network. Also, if a bad guy team is trying to penetrate your deception network, they are wasting resources on something that has no value to you and to them and not directing those resources at your real network. And finally, if you are good at creating fake documents, you can insert a degree of uncertainty into the bad guys' operation. If they know that you are running deception networks and your Cult of the Dead Cow team is good at presenting half-truths and downright lies, the adversary will question the validity of anything that they have stolen.
Rick Howard: Since I was doing it in the Army back in the early 2000s, the technology piece has gotten way easier to manage. There are security vendors now who do this for you - vendors like Acalvio and Attivo Networks and Cymmetria, Illusive Networks, Smokescreen, and TrapX Security. I have not used any of them, so I can't vouch for them. But the fact that NIST and Forrester have included deception as a key component to data loss prevention, I think all of us might start having these kinds of services running in our environments in the near future.
Rick Howard: If I was already down the path of building my infosec program along the lines of first-principle thinking, adding a data loss prevention strategy is probably the next thing to tackle. I would absolutely prioritize identifying your CUI or material data and architect a way to encrypt it at rest as it resides on all of your data islands and as it transits from island to island and away from your control. The next thing to consider is whether or not you have the resources to manage a deception network. It might be too early at this stage for small to medium-sized businesses, but with NIST and Forrester backing the concept, deception networks is something that will likely be on all of our radars in the next few years. For large enterprises and governments, you should probably be looking at pilot projects this year.
Rick Howard: And that's a wrap. If you agree or disagree with anything I've said, hit me up on LinkedIn or Twitter, and we can continue the conversation there. Next week, I have invited our pool of CyberWire's experts to sit around the hash table with me to discuss data loss protection. Don't miss it. 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.
