Modeling Asset Protection for Zero Trust – Part 1

By Andy Ruth, Notable Architect

As you are modeling a Zero Trust initiative into workstreams, a logical separation is by access control and asset protection.  Access control is focused on the request, so identity, device, and network validations. This is like a peephole and lock for the front door. Asset protection is focused on fulfilling the request through the server/service, apps, and data environment. This is like locking up the silverware and valuables in the house. The policy engine and policy enforcement points provide automated control and control points for enforcing access control and asset protection. This is like adding security cameras inside and outside of the house. This article is focused on modeling the asset protection controls of the environment.

Modeling Asset Protection Workstreams

A Zero Trust strategy describes the transformation from a network-centric, implicit trust model to a data-centric explicit trust model that is Internet and digital economy ready. A Zero Trust strategy requires all IT assets to be cataloged with a defined business value. The goal is to design access control and asset protection so that automated rules enforcement can be defined and implemented. The asset catalog with business value data enables operations to prioritize detection, response, and recovery efforts:

Modeling an Infrastructure Workstream

We would love to say, “Don’t worry about infrastructure, it is all good.” But we can’t. And it isn’t. The good news is that the network and infrastructure are likely better maintained from a security perspective than most other areas. The attacks on infrastructure have primarily shifted from brute force to more sophisticated approaches, seem to be trending towards cyber espionage as the driver, and healthcare and education as favorite targets.

The landscape has also shifted with the introduction of Infrastructure as Code (IaC), containers, serverless, and microservices. The shift in infrastructure strategy specific to Zero Trust might be hard to draw, but we absolutely need to know what assets we have, what their business value is, and what the impact on the operations of the business is if they are compromised. We need to know what automated rules and abilities are needed to stand up new instances, operate infrastructure, and, as end-user or clients, gain access to data using applications that run on the infrastructure.

Server patching is still needed but might change as operating platforms move to product delivery teams. Whether specifically tied to Zero Trust or not, Zero Trust does provide an imperative to push infrastructure initiatives through and define ownership (and responsibility) for the use and operations of infrastructure. Hopefully, modeling for this workstream is limited and the bulk of the work is collecting information on what exists and what is needed. Some keys to getting started:

• Ensure you have a complete inventory of infrastructure assets, some form of business impact, and value provided (and at risk) for each asset.
• Ensure the use of IaC in the application development process is defined and followed and that the images are patched and maintained.
• Ensure infrastructure provisioning is automated, and that you can verify host configuration and supply chain provenance and integrity for all technology components.
• Ensure incident response processes are defined for all instances of infrastructure, including virtual machine (VM) usage, app development, front-end, middleware, back-end servers, and productivity platforms.
• Ensure the infrastructure follows a versioning scheme, that the live version has no administrative privilege available (is effectively read-only), and patching is primarily achieved through versioning.

As you start your modeling process, consider including all the technological assets that might not be represented in any of the other pillars. You can decide later who ultimately has ownership and responsibility for technology, but better to be aware of a class of technology that is not assigned correctly than to have one forgotten. To start your model, consider creating five boxes:

• Serverless
• Software-as-a-Service (SaaS)
• Platform-as-a-Service (PaaS)
• Infrastructure-as-a-Service (IaaS)
• Other

You might find you need to separate by on-premises and off-premises or that using a back-end/middleware/front-end/edge/other structure makes more sense. You might also find you need to create buckets for containers, VMs, or edge servers. As the team of architects and experts who help with this effort starts, make sure they do not feel constrained by your starting model. As part of the process, encourage participants to play with the structure and adjust as needed. The starting point could look like this:

With luck, you’ve already got a solid naming convention for infrastructure and a good, detailed mapping of each infrastructure asset with other key information. And hopefully, you have a solid (and as automated as prudent) approach to patching. This exercise might be a review of existing data or a restructuring of the data to support the overall Zero Trust modeling process.

A good next step is to determine the level of automation and tools in use for defining and maintaining infrastructure. Again, hopefully, you’re already steps ahead of this. If not, using IaC can:

• Speed time to production or market because the environment is codified, and documents and human error are greatly reduced.
• Limit configuration drift and increase consistency by ensuring the configuration between development, test, and deployment environments remain consistent and are in a known state.
• Faster, efficient development as the developer team enjoys having a near one-click environment hydration process. This removes the environment as a variable for inconsistency as development work begins. This also removes the delay or churn that can occur as environment creation is not dependent on a limited number of people that might be on vacation, out sick, or moving to a different team or company.
• Lower cost of development from the efficiencies listed above. The cost reduction and improved stability can be used to justify any initiative to shift to IaC.

With IaC, there is a balance or tradeoff that comes down to the ability to modify and control the environment that people have. The more control people have, the less consistent and efficient the environment. Conversely, the less control people have the more efficient and consistent.

Whether you are collecting information on existing IaC capability or using the Zero Trust initiative to provide IaC capability, you must make sure you determine whether your approach is using mutable or immutable infrastructure, a declarative or imperative approach, and what tools and templates are used for environment definition. There are dependencies you must consider as you design the environment. For example, a mutable environment can be modified after its original provisioning. An immutable environment can’t be modified. We recommend an immutable environment, however, some considerations in making your decision include:

• A mutable environment provides more flexibility for the development team to react to customer feedback, respond to emergent security issues, and make changes to their environment.
• A mutable environment that can and is modified might limit the ability to maintain consistency between deployments or within versions and can hamper infrastructure tracking capability.
• An immutable environment “hardens” an IaC environment as it cannot be changed so the alignment with governance, reduction of drift, and consistency between environments and versions is maintained.
• An immutable environment requires one or more experts to create and test the definition. This might introduce a bottleneck to requests for changes to a given environment and might have a negative impact on productivity and a team’s feeling of independence.

A declarative approach is considered a functional approach where you define the end state and the IaC software and tools take care of the details to get there. This is like using a serverless workflow – you define the workflow and a serverless, unknown thing completes the tasks in the workflow and provides the answer.

An imperative approach is considered a procedural approach. An expert defines each step in the environment definition. This is more like a PaaS or SaaS solution – you define it all and have full control over everything.

Note: If you’ve got to discuss this with leadership to get an endorsement, don’t use the PaaS/SaaS/Serverless as an example. Rather use a GPS versus personal/navigator discussion as example. For example, with GPS, it takes an expert to set up the GPS and device, but it is easy to use as you just plug the destination in once it is working. The tradeoff with GPS is you get the directions the GPS gives you with little or no understanding or control of how the GPS derived the route. With the personal/navigator approach, you use personal experience to determine the route. Works great but you might need to call for help if there are temporary obstacles, you want a more efficient or more scenic route, or are going to a new destination you’ve not been to.

Some considerations for choosing a declarative or imperative environment:

• A declarative approach requires an expert to set up, and the experts typically specialize in a specific product or tool.
• A declarative approach is easier to use once set up, but you have no internal expertise for maintaining or updating it.
• An imperative approach requires you to build the automation scripts yourself, but the tools and guidance make it easy enough to accomplish and you grow organizational expertise.
• An imperative approach might not scale well as it requires internal resources to set up the scripts which might lead to a bottleneck.

As with every decision, there typically are no right or wrong decisions, just tradeoffs and living with the decisions. The last area of consideration or piece of information to gather for IaC is what tools and templates are in use (which hopefully they are). The tools and templates are built for specific combinations of mutable/immutable, and declarative/imperative decisions. You must decide if the tool is key and the decisions follow the tool, or if the decisions drive tool selection. The following is a chart you can find in an IBM blog post titled Infrastructure as Code: Chef, Ansible, Puppet, or Terraform.

If your product development teams are using agile or DevSecOps-styled approaches for product development and delivery, then they hopefully are using some automation for version control and configuration management. If so, this might influence the approach and tools used for infrastructure. For example, Terraform works across all cloud providers, provides orchestration capability, and has coverage for the entire lifecycle. It might be a good choice if your product teams have already selected various tools for their product provisioning and management. But Terraform is immutable and declarative so might change your choices for infrastructure.

For operating your IT environment, the Security, Information, and Event Management (SIEM) system must be a good fit for the infrastructure. Once you have a complete inventory of your infrastructure, we recommend you complete an architectural-level evaluation of your SIEM to ensure good alignment. At a minimum, we suggest you evaluate IBM QRadar, Splunk Enterprise Security, LogRhythm, McAfee Enterprise Security Manager (Trellix), Elastic SIEM, and Microsoft Sentinel. The evaluation should include the cost of setup and three years of operations, evaluation of organizational competence and available training for each, and the features of each against your IT landscape.

As you evaluate your SIEM environment, consider evaluating your Extended Detection and Response (XDR) capability and performing a similar architectural evaluation. You might consider this part of your SIEM solution or treat it separately and it might be operated by a separate group. XDR also might not fit well into any pillar evaluation so could be overlooked if not captured here.

Zero Trust requires identification and valuation of all information technology (IT) assets, automated enforcement of governance, and automated detection, response, and remediation to threats and attacks. The number of releases and updates to the operating environment can easily be in the thousands daily, and the number of attacks can easily reach ten or twenty million each day. Knowing what you have, what it is worth to the business, and a robust set of automation tools are essential to achieving a Zero Trust security posture. How you model and structure your infrastructure should support these Zero Trust goals.