Years ago as a brand new IT manager I was given a project: Make the client HIPAA compliant. Multiple hospitals. Even more health centers. Affiliate and third-party network access. No budget. No additional staff. No relief on existing deadlines.
I sat and reflected. Then I wrote a two-sentence resignation letter.
Outside of my manager’s office I was working on my “Paper or plastic?” delivery, and it felt good. Ready to embark on the next phase of my career, I walked into his office and handed over the letter. He sat down, read it, and then asked, “How do you eat an elephant?” He and I got along well and I respected him. In particular, I liked the stories from his Marine Recon days in Vietnam - you know, the stories he could tell me without having to kill me. Considering his past, I completely accepted the idea that he did, in fact, have the skills to properly field dress and eat an elephant, and I was thinking this was a lead-in to another story. I just didn’t expect the sudden change in topic while I was trying to resign.
“… I’m sorry. What?”
“How do you eat an elephant?”
“Still not following…”
“One bite at a time.”
The First Bite
I would wager that most of us are in agreement that our critical infrastructures, and control systems in particular, are facing serious cyber security vulnerabilities. There is no shortage of news stories or blog posts decrying this state of affairs and demanding that something must be done. Sure, but where do you start? Designing and deploying a cyber security program is a daunting undertaking, and I have seen many an organization suffering from analysis paralysis end up doing nothing - and that benefits no one. While a daunting undertaking, it’s not an impossible undertaking. It just takes that first bite. Here are some considerations to get the ball rolling:
Ask Yourself: “Why am I doing this?”
It seems a pretty logical question, but over the years I’ve been surprised at how many organizations would start a cyber security project without understanding why they were doing it. Are you subject to NERC CIP or other standards or regulations? Have you been breached? Was there an internal audit finding? Regardless of the answer to these questions, you’ll likely deploy the same technologies, but how you deploy them and in what order may be vary greatly.
From Drought to Flood
Based upon your project goals, you can then define your top 3-5 use cases and these should be fairly limited in scope. Why do this? Do this because you will be deluged with security event data, and limiting the project to your initial use cases helps provide much needed focus. Otherwise, it will all become white noise and you might as well having nothing. Imagine walking into The Home Depot, and asking “So, what can I do with all this stuff?” rather than walking in with a shopping list of materials needed for your weekend project.
You will also need time to investigate your initial results, adjust baselines, and establish processes. Your initial discoveries will certainly lead to additional use cases, so starting with 3-5 will not be as restrictive as it may sound. For example, starting with whitelisting and passive network monitoring on your control network, you may discover forbidden protocols on your control network or unknown communications with the corporate network. That would logically lead to further investigation and use cases.
Jason Bourne vs. George Smiley
Uber-malware such as Stuxnet gets all the press while a simple Shodan search and default credentials get bupkis, but which is the greater threat? I have found a tendency in some organizations to be so concerned about detecting complex methods of attack that they ignore the basics such as disabling guest accounts or changing default credentials. In most cases, why would a nation-state invest the money and talent in creating more malware when the barriers to entry are so low? For all the sophistication of Stuxnet, it was the simple act of plugging a USB stick that helped destroy those centrifuges. Imagine if Natanz had a simple, enforceable policy to detect and block USB sticks on the network.
Dessert
The role of the ICS-ISAC is, of course, to share the collective knowledge of its members so that all benefit from our extensive and varied experiences. One way this will be achieved is through the Situational Awareness Reference Architecture (SARA) project. If SARA is done correctly it should provide a menu of bite-size portions. The first step in SARA is determining Identity (“who am I?”) which will lead to why you are doing any of this. Next is determining Inventory and Activity, which will help control the flood gates and address the George Smiley threats. Where each facility can get that basic work done they will be well positioned to chew that final SARA step: deciding what knowledge to start Sharing with whom.
If we can all focus on taking the bites that make up SARA then they, and the rest of us, will find that we have gotten down to picking the last bits of meat off the elephant bones and choosing sweets and coffees.