Not Your Grandfather’s Empire I’ve wanted to put this blog together since returning home from DEFCON. Anytime we ran into someone who recognized our swag, they mentioned how much they loved Empire back in the day and didn’t realize it was being actively maintained. This made me reflect on all [...]
Recently, while discussing cyber risk management with a customer, they made the observation that there is a lot of training for top-level risk management in the shape of things like CISSP that focuses on building policy. There is also a lot of training on technical details, but there isn’t much information on how to transition between those plans and the technical details. Let’s say your network admin has suddenly been tasked with implementing security at your company. Where do you start? How do you determine where to spend money first and what tasks should be prioritized? So, to help remedy that, this will be the first entry in a series of articles on applying system engineering to evaluate a business and start building those implementation plans.
When I worked at the Air Force Operational Test Evaluation Center, we were tasked with evaluating the effectiveness of weapon systems. Specifically, we tested fighter aircraft. One aspect of this was identifying vulnerabilities in the weapon system. This was not specifically about cyber vulnerabilities but anything that could be identified as a combat weakness. So think something like if the fighter couldn’t detect a target if it came from the aircraft’s left side, That would be a significant combat vulnerability but not a cyber one. We did this by conducting live testing with the aircraft, but before that, we sat down and conducted a process known as functional decomposition to help us design our tests.
Functional decomposition is a system engineering process by which you break down a complex system into a series of functions, allowing you to evaluate individual functions and processes better. From there, you can break each of those into smaller functions and so on. If that sounded a little abstract, it would make more sense with an example. So, let’s look at an airplane. I’m partial to the F-22 since I ran the first cyber assessment against it.
Traditionally, when doing a functional decomposition of an aircraft, there are three core functions that make it an aircraft. The ability to aviate, navigate, and communicate. In other words, it must be able to fly, know where it is, and communicate with other aircraft and air traffic controllers. If we create an engineering diagram, it starts to look like this:
From there, we could take the aviate block and further break it down into take off, fly, and land. That gives you the gist of how it works, but this blog’s title refers to organizational cyber risk, so how does this apply? Well, a business can also be represented as a system. It has a core mission that it is attempting to achieve and thus has critical functions that it must complete in order to achieve that goal. Let’s move on from the airplane and refocus on a simple business, a lemonade stand on a street corner. This lemonade stand is making lemonade by hand and selling it to people who happen to be walking down the street towards the park.
To start the functional decomposition process, let’s identify the core activities needed for a lemonade stand to operate. You could go about this in several ways, as this process has some subjectivity, but I will define three core functions as: Procurement, Production, and Selling. That is, we need to be able to get the ingredients and supplies to run our lemonade stand. We then need to be able to make the lemonade and finally be able to sell our lemonade. So here’s our starting chart:
Next, we start breaking down each function, starting with Procurement. This will include everything from getting the lemons and sugar for our lemonade to the cups for serving and materials for making signs. This is still at a relatively high level, but when breaking down an existing organization, it can be helpful to look at its current business practices. In this case, the lemonade stand has all supplies delivered to them instead of going and getting them. As a result, I will break Procurement into the following three functions: Order, Receive, and Pay.
Next, let’s analyze the Production function. Again, we need to look at how the lemonade stand is conducting this operation, and it turns out that everything is done manually. No electronics are used in the process; all ingredients are received in the morning, and the lemonade is served with ice to eliminate the need for a fridge. We can break this process down into Prep, Mix, and Clean. Here’s where we can start applying our cyber lens and leverage some of the effectiveness of this methodology. We have identified no processes in this branch of our decomposition and can truncate the analysis here.
Now, it’s rare in real life that you will have this clean of an answer at this high a level, but it shows how you can use this process to begin enumerating the threat surface of the company. It also allows us to quickly identify where we should focus resources, especially in organizations just starting to invest in their security architecture.
After that, we analyzed the final branch we identified: Selling. This is everything post-production and includes taking the customer’s order, serving the product, and accepting payment. That’s actually a good way of identifying the three core functions that we are going to analyze. So, this is what our chart looks like after our tier two analysis:
During a real analysis, we would continue this down for a couple more tiers until we identified the core underlying steps for each business function. When applying functional decomposition in this scenario, identifying a business’s core processes/functions can also be called a Mission Analysis. This is the first step in what is known as the Mission-Based Risk Assessment Process for Cyber (MRAP-C), which is a cyber risk analysis framework that the DoD published and Anthony was involved in helping shape. We use a modified version of it at BC Security, but the process can be roughly broken down into these phases:
1. Business Analysis
Identify Business Objectives and Critical Processes: Determine the critical functions and operations required to achieve business goals.
Develop Operations Threads: Analyze business operations to understand the sequence of events and processes critical to mission success.
2. Threat Assessment
Identify Threats: Identify potential cyber threats that could impact business operations at critical points identified in the business analysis.
Threat Analysis: Assess the capabilities, intentions, and potential impacts of identified threats on business objectives. Identify the sophistication of the probable threat actor.
3. Vulnerability Assessment:
Table Top Analysis: Leveraging the threats identified during the Threat Assessment phase, conduct a thorough review of the current state of the business operations and identify critical failure points, mapping functions to hardware assets
Evaluate Vulnerabilities: Conduct vulnerability scans, penetration tests, and asset cataloging to validate assumptions made during the Table Top Analysis. Evaluate real-world implementations vs documented expectations.
4. Risk Assessment:
Risk Analysis: Based upon validated findings from the Vulnerability Assessment, produce risk reporting for the organization.
Risk Prioritization: Prioritize risks based on their potential impact on business success and the likelihood of occurrence.
5. Remediation and Residual Risk Identification
Remediation: Investment of funds and execution of fixes and changes required to address the prioritized risks. This step may be measured in months or years.
Residual Risk Identification: Once individual risks have been remediated, conduct a reanalysis of the business to identify the remaining risk
So far, we have conducted the Identify Business Objectives and Critical Processes step for our lemonade stand. We have identified the core functions we will analyze in our Operation threads. The operation threads serve two functions. First, they give us an attack vignette to build a real world application and sequencing for the functions. Second, they allow us to start mapping functions to components. As we will see in our next installment in the series, sometimes multiple functions are handled by a single system, increasing its importance and the likelihood of being attacked.
Reporting is, by nature, only the threat actors that have been caught. What about all the ones that didn’t get caught? There is no way to examine that and It ...