How to Develop a Secure System in 6 Easy Steps: Step 1)

I keep reading pieces on secure software development, technical security measures, cool security tools, etc, but not a lot on the big picture of secure system development (at least in easily digestible bites). I’m going to take a stab at writing down my own thoughts on this and distilling the process into a simple roadmap, with the theme being to capture the big flows, not the details. None of this is new - all is covered by Ross Anderson, Bruce Schneier, the NSA IATF, the NIST 800-160, etc, etc. What makes this information so useful is that all the ideas and concepts are well worn. Also, because all of these concepts are well worn, I will not try to annotate and footnote the content; if you need that level of detail, I suggest hiring a System Security Engineer. You can attempt to Google the subjects, but context and experience matter more than you might think. Google aside, hopefully this stab will help someone, somewhere, think through their own challenges with a little more clarity.

That rambling intro complete, here are my 6 steps (admittedly 6 steps short of a full recovery, but this is a free article in my spare time…): 

• Step 1) The What: Understand what you are trying to protect
• Step 2) The Who: Understand who needs to be involved (security is a matrix, not a person)
• Step 3) The Budget: Understand your scope
• Step 4) The Design: Work down the stack and across the system
• Step 5) The Implementation: Test, test, test (and test again)
• Step 6) The Delivery: Systems don’t exist without end users

I’m not going to try and hit all of this in one posting, so my goal will be one post per step. This post is the intro and Step 1), The What.

The What is fundamental to security execution, but often sped by on the way to buying shiny new tools to go about “securing stuff”. Maybe your company is so small or has such big pockets that you just want to protect everything and be done. This is usually not the optimal path. Some things need more protection that other things, and you want to allocate finite resources accordingly. The “what” is generally divided into two distinct security problems: critical information and critical functionality. The critical information is just that - information that is important to your organization. This could be personal employee information, intellectual property, financial information, whatever bits of data have an operational or compliance impact. You create this list by talking to all the stakeholders of your business -- the accountants, executives, attorneys, engineers -- the list goes on depending on your organization. Whoever you get involved, you need to come up with a high level concept of what is and what isn’t important from a protection standpoint. And this list should not be huge. If you have 100 items you have most likely overshot. You need to think of this at the “annual budget information” level, not the “Alice’s 2018 budget spreadsheet” level. That comes later. 

As you are forming your list of critical information items, you also need to determine what type of protection each item needs. We are still not at the “firewall / DLP” detail yet, but we need to understand why the information is important to tailor what kinds of protections to apply. This is where we first touch on the traditional security trident of confidentiality, integrity, and availability (CIA). This part of the process may also be broken down into two primary piles 1) sight sensitive and 2) modification sensitive. Sight sensitive is just what it sounds like: you don’t want anyone looking at it. The confidentiality and integrity needs are important. Modification sensitive is also what it sounds like: you don’t mind outsiders seeing the information, but you don’t want them to change it (and use it in a different way or mislead someone with it). For this information, the confidentiality needs are low, but the integrity needs are still high. For both of these, availability concerns may be high or low, as required by your operation. You can break information down into even further refinements, but each item on your list should have at least one of these categories assigned to it. 

Critical functionality is sometimes overlooked. These are functions that impact your organization’s operations, but tend to be more activity related, not things you read on a screen. Integrity and availability are primary concerns for critical functions. Again, don’t drill this down to “our Cisco NNNN backbone router”, but think instead “connectivity to our clearing house” or “office air conditioning” (at least if you want people in your office during a Texas summer). And review all your operations and business processes. This is particularly important for critical functions, as organizations tend to bake in processes and functions to the point that you a team of PhD Anthropologists to dig them out.

One of my favorite stories from “The Innovator's Dilemma” is about a sausage company and a bicycle cart. I won’t spoil the entire story (read the book if you haven’t), but the company discovered that a bicycle cart was a critical function of the business, and when it was removed, their product suffered. This raises another key point of this process: security is still a physical thing. With the emphasis on Cyber, there has been a mindset creep that security may be accomplished by people sitting in cubes, or in a darkened SOC, using remote access. This is fundamentally incorrect. Security, even Cybersecurity, is still very much a see, taste, smell, and feel activity. As you collect your critical information items and critical functions, you need to walk away from your desk and engage. Dig, chat, follow the guy pedaling the cart full of sausage, whatever it takes. One of the best discovery sessions I ever had occurred over half a bottle of tequila. One day the world may run on AIs, but at the moment people make or break security decisions.

Once you know what you need to protect, you can then move on with refinements to the protection picture. For NIST RMF this would be the categorization based on the confidentiality, integrity, and availability (CIA) needs you outlined above. Other processes have similar gears to turn. The important piece to walk away with here is that all the processes, NIST, ISO, whatever, depend on you having clarity for what you apply the process to. You have to understand "how big is the box" before you start buying the paint. As an example, for NIST RMF, people get wrapped around the axle about whether integrity is moderate or low. The difference is a handful of controls that can be adjusted as your work the process. Far more important from the standpoint of cost and schedule is not identifying all the items that need protecting, or identifying something shouldn't be on the list. An “oops, we forgot that” or "well that was $5M wasted" at the end of a project is a far bigger headache than refinements to development that is underway. 

I’m at the end of this post (my goal is to keep these around 1000 words; short enough to be read on a break). Before I leave though, I want to touch on one last thing to remember as you work through all the steps: Amor fati. If you want to embrace creating a secure system, you must embrace fate. As you figure out what to protect in your system, as you figure out who to engage to get the protections in place, you are going to find problems. You must embrace them. Don’t worry about the whether a problem is good or bad, just embrace what it teaches you and move on. Perhaps that is Step (0): get your mind straight about the task ahead. Embrace the chaos and ride it down. When you start an effort you are riding shotgun down the avalanche, because the world doesn’t freeze frame while you work things out. 

So keep your head up, watch for the trees, and ride that avalanche. 

jon