How Much Trust?

How Much Trust?

I simultaneously love and loathe “Zero Trust.”

As stated in the original concept by Forrester, Zero Trust means that we must abandon the concept of an internal, trusted network separated from an external, untrusted network, and instead assume all traffic — regardless of source — is not trustworthy. It means we should inspect all network traffic on the assumption that something bad may appear in any segment, whether that’s evidence of malicious activity, misconfiguration or poor performance.

In the ultimate Zero Trust environment, network traffic is inspected and analysed at every network interface, and each interface restricts traffic to only what is explicitly authorised (“least privilege”) based on network or application requirements.

 

Matthew Todd, principal consultant, Full Scope Consulting LLC

 

Zero Trust Pros and Cons

As a security professional, the concept of Zero Trust is appealing: limit network traffic to only what is needed, inspect and analyse everything, and ideally have the tools and resources to quickly identify something wrong and react appropriately.

The problem with Zero Trust is that, at some point, the security team needs to interact with the rest of the business.

 

Imagine the conversation:

CTO: “So, Bob, tell me about this big change to our network.”

CISO: “Well, Alice, we’re implementing a Zero-Trust model.”

CTO: “What does that mean?”

CISO: “Basically, it means we don’t trust anything.”

CTO: “Or anyone?”

CISO: “Right.”

CTO: “Like my engineers?”

CISO: “Oh, yeah, definitely not your engineers.”

CTO: “It’s no wonder you’re never invited to the holiday party.”

From a CISO’s perspective, to truly protect the enterprise, it’s best to trust nothing and no one. Yet that’s not a great way to run a business (and most certainly not a good way to make friends).

 

Delivering the Largest Playground

We security professionals must acknowledge that various teams must be trusted with a certain amount of access to do their jobs. Some staff need access to very sensitive things — like accounting software or production databases — while other staff need flexibility to experiment and create new things.

So while we work to monitor and analyse all traffic, we need to remember the realities of a changing business environment. How can we appropriately limit access to controls and data while not standing in the way of innovation?

 

The answer is we have to think about trust in two seemingly contradictory ways:

  • On the one hand, we can’t afford to treat any part of our network or our application infrastructure as trustworthy, so we must vigilantly observe and analyse all activity on networks, systems and applications.
  • On the other hand, we must afford our corporate teams the resources they need to do their jobs effectively without constantly asking permission for access, so we must understand how various teams work and proactively prepare.

 

Here are a few examples of what I mean:

Teams such as accounting, legal, and human resources can typically work in highly controlled and seldom changing environments that other teams rarely need to access. We can take advantage of this dynamic and carefully restrict access to the services and applications that these teams use. Similarly, we know these organisations will rarely need to access other resources such as development environments which lets us close off and monitor access from these teams to those other environments.

Engineering is different. These teams have to be able to quickly access a range of resources that change over time as new features are tested and new services are rolled out. For organisations like these, the goal is not what is the minimum access we can grant, but instead it’s what’s the largest playground we can provide?

The difference between minimum and maximum in this scenario can be the difference between slow development cycles, hampered by a morass of security roadblocks, and an agile, smooth development process. We still must carefully control access to sensitive data, controls and networks, but we must also look for creative ways to give these team members the room they need to work effectively —  and adjust as tools, resources and needs change.

 

Are we losing the fight against cyberattacks?

READ MORE

 

Trust, But Verify

Zero Trust and least privilege are effective security models. However, they must be enforced within the context of an agile business if we security pros hope to be seen as effective partners to our colleagues.

With Infrastructure as Code and software configuration management tools, we now have effective tools and techniques to provide secure building blocks to IT and development teams. This means we can simultaneously give engineers the flexibility they need and build in the security and monitors we require to enforce Zero Trust at the infrastructure level. Similarly, direct engagement between the data and software architects and the security team ensures that monitors and controls are properly built in to applications.

Ensuring trained SecOps engineers are part of IT projects means that controls and monitors are in place for corporate application projects. In all cases, building security in early and often means that we can make sure we have the means to monitor all of our networks and data — a critical component in the Zero Trust model.

By no means should we ever grant access to sensitive controls or data unless it’s needed, but there’s a lot of room to play. We just need to take the time to better understand the context in which our peers’ teams need to operate.

If it helps, remember the Russian proverb President Ronald Reagan used: “Trust, but verify.”