In part 1 of this series, we introduced the basis for control design through an organizational business model. Subsequent blogs demonstrated various views and dimensions from which to consider control design and implementation that complement the multiple dimensions from which an organization must be protected. Using elements of inversion modeling, we will take the causal models derived from the business model for our fictional company, ECS, to develop our high-level protection strategy. The business model is the system we used to quantify organization priorities, then apply deductive logic to derive the possible conduits of access, types of access, mandatory directives, and threat landscape.
Business Requirements — System Parameterization
In inversion modeling, system parametrization is the act of defining parameters from which a system can be modeled or observed. Here’s how it works: (1) The system we are inverting is the business model of which the functional components equate the parameters of that system. (2) Inversion of the functional components derives the operational components that equate parameters of that system. (3) Inversion of the operational components equate the parameters of that system, which is qualification of business priorities. The causation model in shown in Figure 1.
It is against business priority enablers that we align the following causation models required to present our high-level protection strategy.
Causal Model 1 — Threat Landscape
We captured the business priorities in the business model’s value proposition. ECS’s desire is to “offer certified and compliant cloud computing services secured with the leading security standards.” Delivering on that priority requires ensuring the protection of enablers. Of the causal models derived, inversion of the threat landscape and executive threat model provide the following enabling parameters:
- People Resources
- Hosting Resources
- Service Resources
- Technology Resources
The enabling parameters provide your organization with the functionality required to fulfill the value proposition. From a business perspective, they provide framing of functional requirements.
Causal Model 2 — Control Ladder
By consulting the business model and reference architecture, we were able to model the control ladder for ECS through inferences based on observing key partners, channels, and customer segments along with the hosting and capability domains that enabled modeling of the various controls. For instance, providing partners access enabled us to observe information flow, which resulted in the inference of the threat flow control component. Protecting partners and the customer segments led to inferring the need to protect based on situation, which resulted in the two-tiered amplified situation control component. Collectively, each control component of the control ladder provided the technical requirements necessary to fulfill the functional requirements, with the parameters embedded within each component below:
- Foundational
- Environmental
- Functional
- Situational
- Threat Flow
Protection Strategy
Protection strategy is best designed to support the value proposition of the business. Combining and ordering the parameters associated with causal models 1 and 2 provides a blended view at a high level for executives to communicate intent and goal along with subjective quantification of effort. Based on the case scenario (ECS), objective inferences were made to complete the traceability matrix shown below.
This view demonstrates how well prepared your organization is to meet the functional requirements. At the same time, it provides traceability to the various causation models derived from your organization’s business model. A more detailed traceability matrix might list the actual solutions used such as firewalls or antivirus. In the real world, expect to see more red because security is an incremental journey.
Wrapping Up
Thorough analysis of your organization’s business model is the first step in understanding the various dimensions of attack. Next is recognition that control effectiveness must be measured differently than the current “check-box” method which, when measured against the various dimensions of a business, are less than adequate.
Engage your technical staff in on-going discussions of control design from views that support traceability, interoperability, and scalability. Encourage the use of information modeling to rationalize strategy and tactics; expect attaining and maintaining a protection strategy aligned to the business.
There is one more important takeaway from this series. Remember to keep your business model as confidential as possible. It is quite easy to use the same tactics covered in this blog to perform reconnaissance against your company, which is the first step to compromise by an attacker. Why? Because deductive logic, inference, and inversion are another way to say “reverse engineer,” which is just one of the ways attackers think.
