Zero Trust is Genius & an Oxymoron – Part II

In the first blog, we covered the problem of implicit trust built into systems. On the business side, this is partially why you’re paying a premium for operational support and risk management. On the tech side, this is partially why you have to request more tooling and integration to meet security, compliance, and cyber insurance requirements. These two sides of the equation sometimes feel like there’s an angel on one side and a devil on the other when it’s time for any business-aligned technology decision. Discerning who is who becomes difficult as we wrestle with the competing factors in play. What if there was a better way?

Today, we look at how AWS natively aligns with commonly held tenants of zero trust (according to NIST 800-207 and the updated Zero Trust Maturity Model v2). In this blog, we focus on serverless SaaS because it delivers significant business and technical benefits, specifically reducing the work required to mature and manage the identity, network, and data pillars, effectively eliminating the device pillar for any serverless SaaS application. Finally, it streamlines and automates the applications and workloads pillar.

If bringing peace between both sides sound interesting, read on…

Where Angels Fear to Trea

Those zero trust tenants defined by NIST want us all to go where angels fear to tread…. Fear not! Those tenants are baked into the AWS platform, where all data and computing services are considered resources that can be abstracted and isolated, all communications are secured using TLS (with perfect forward secrecy). Access to individual resources is granted on a per session basis, determined by dynamic policy, the security posture of all serverless assets is monitored, and measured, their current state collected and can be used to improve your security posture. Finally, all resource authentication and authorizations are dynamic and strictly enforced before access is allowed. (I just saved you 5 minutes of reading the NIST tenant’s section.)

NIST Zero Trust tenants are baked into the AWS platform.

Looking at it from the AWS perspective brings additional depth to the conversation about zero trust (as discussed in the Zero Trust architectures: An AWS perspective and How to think about Zero Trust architectures on AWS blogs). In a nutshell, it just puts technologies deployed behind the perimeter into buckets that can be defined and protected effectively.

Traditional network-/perimeter-centric trust models expand to include identity centric controls, and application components or microservices that are independent from each other. No component or microservice trusts any other because the input from any source (including another app you created) can potentially become malicious.

Using cloud native serverless technologies means all services are visible to the AWS Config service, which can be used to continually monitor and validate the configurations for those services to meet your policy requirements. It also means there are no blind spots in the serverless cloud like there can be on-premises.

I say this with a tear in my eye, remembering my days as a network engineer for the Marine Corps where I spent days trying to troubleshoot a “network” issue, which tuned out to be an undocumented server issue found on a filing cabinet. Today’s Top Tip, “hiding” a server on top of a filing cabinet by putting a flowerpot on top of it is bad. Flowers need water, which is really bad for electronics….

Another good reason to embrace a serverless model, if you were looking for one, is that you have 100% visibility into all the requests made by people and machines to a resource. All requests require a principal, which is a user or a role, and you use policies to define who can take actions on specific resources. And you don’t have to worry about flowerpots or filing cabinets. There are a bunch of additional tenants and assumptions in various ZTA docs, but I just saved you another 5 minutes reading about legacy and on-premises trust assumptions and issues that cloud has made meaningless.

There are no blind spots in the serverless cloud,
and you don’t have to worry about flowerpots or filing cabinets.

Also, I’ll tell you in a minute why I keep telling you how much time I’m saving you. First, I need to give some technical data points that enable the business value conversation.

Technical Data Point #1:

Building on the AWS Nitro System is the best way to quickly and cheaply remove the legacy “implicit trust” from your infrastructure.

In 2010, the concept of “zero trust” came to life from Forrester Research analyst, John Kindervag, who presented the idea that an organization should not extend trust to anything inside or outside its perimeters. In 2017, AWS released a completely redesigned hardware architecture implementing zero trust in hardware to improve security, isolation, performance, and cost. This is one of the most zero trust architectures commercially available.

Couple of points about Nitro. First, it provides the hardware root of trust for the overall system, which is the only trusted interface between a server and the network. This goes a long way to breaking the implicit trust that exists today in most other systems. Second, Nitro extends a chain of trust by measuring and verifying firmware stored in flash. Third, its Passive communications design extends zero trust concepts to also provide detective mechanisms. A vulnerability or breach in downstream supply chains will be detected because Nitro “operation involves listening only for well-defined, parameter-validated messages and responding to them using well-defined, parameter-validated responses.” To simplify, the system is designed to not trust other components, and to clearly identify and alert on potential aberrant activity. These are capabilities you can inherit from AWS without any additional work on your part.

Technical Data Point #2:

By default, the AWS IAM Service doesn’t trust anyone and the policy language is granular enough to explicitly allow only least privileged access.

By default, nothing outside the original root user is trusted in an AWS account. You need to create users or roles and policies to allow access to resources, data, and networks for anything to work. And you can scope down the access by using conditions in your policies. For example, denying access if MFA was not part of the authentication process, limiting access based on time of day, IP address, user agent, userId, Federation source, AWS region, and so many more. The point is you can get granular on ZT access policies. You can also implement Attribute Based Access Control (ABAC) using policy conditions and tags to supplement global condition and get laser focused on your zero trust policies.

AWS Nitro and IAM are just the tip of the ZTA iceberg on AWS. But I need to move along because icebergs melt and according to Techjury, (1) you only read a blog for 37 seconds and (2) if I don’t include meaningful images to express ideas, I’ve already lost 45% of you. So far we’ve included four charts, but I’m well past the 37 seconds.

If you’re still with me, it’s a miracle, and I thank you.

In any good business aligned technology discussion, we must tie the technology and business benefits together.

Technical Data Point #3:

You can align your business and technology strategies through the Shared Responsibility model.

Since everyone should be a hero in their own story, I’ll use you for this talking point.

Let’s say you want to build a SaaS application on AWS, because you want to fully leverage the security and zero trust capabilities of AWS. After hundreds of hours reading the bazillion pages of surprisingly useful documentation on AWS, you conclude you have to go serverless because

• two people have left your department, leaving gaps in implementation and support;
• you know the security and compliance team is struggling to find qualified people at a salary your org can afford, causing delays in pushing new apps and updates – which have been projected to boost revenue – to prod;
• your current app is having uptime issues, impacting customer satisfaction;

and so on and…

When you address this talking point, explain it this way:

The AWS Shared responsibility model is like a genie in a bottle.
All you have to do is pull the cork and AWS does the rest.

The shared responsibility model is the most strategic option because it aligns business and technical interests, demands, and value. Here’s a handy comparison with two diagrams you can use to really demonstrate this point.

The traditional IaaS AWS Shared responsibility model, for example building your SaaS app on EC2. In this model you are responsible for almost everything.

The serverless Shared responsibility model for Lambda, is where AWS takes much more responsibility versus the EC2 model.

With Lambda, AWS has operationalized scalable, highly available and secure architectures at a price point that is a fraction of what it would cost you to do by yourself. This is a core value of serverless.

Services like AWS Lambda and AWS Fargate run on the AWS Nitro System, and use the AWS IAM Service to provide enhanced security by continuous monitoring, reducing the attack surface, offloading virtualization and security functions to dedicated hardware and software and providing granular and flexible identity based ZTA policies.

Don’t believe me? Take a look at The Security Overview of AWS Lambda whitepaper and tell me (1) how you would get this level of security using traditional methods and (2) how much would it cost you to build, operate, and maintain that highly available system? Sorry, you just can’t get there from here and sustain your differentiation, while remaining competitive in commercial and/or public sector markets.

Here’s the rub. If you want to evolve from a traditional enterprise stuck in the initial stage of the Zero Trust Maturity Model (v2) to the optimal stage that “features more dynamic updates, automated processes, integrated capabilities,” you need to get your mind wrapped around the well architected, best practice driven serverless SaaS model for application and infrastructure design.

This is the most effective path to accelerate your zero-trust journey, reducing risk and cost while growing organizational effectiveness and maturity.

How you think about and plan your journey directly impacts what capabilities, costs, and risks you can avoid, mitigate, or transfer to your cloud provider. It also leads you to a better place where the only devil is in the engineering details, not from business and technical problems created by the implicit trust built into traditional systems.

About RockITek, LLC | RockITek is a progressive Technology Partner + Enterprise Distributor to manufacturers of revolutionary technologies that have the potential to impact the world. We thrive at solving problems faced by the thousands of Independent Software Vendors (ISVs) with trailblazing software capabilities being marketed across a variety of markets. Our unique approach rapidly matures and continuously maintains the security of your SaaS to US government standards; automates cloud marketplace(s) and enterprise transactions from purchase to deployment to payment; and creates an enabling ecosystem for continuous growth for all partners. We are a small business (NAICS 541519) with a GSA Federal Supply Schedule 47QTCA19D0085.