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:
- Threat Flow
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.