Zones of Trust

The key security design decision is the balance to be taken at every step of a system design between trust and inconvenience.

For every system to system, subsystem to subsystem and component to component connection a decision must be made as to whether either side of the connection will trust the other, and to what degree. Trust is in some ways analogous to coupling. The higher the level of trust, the more likely that a compromise of one side of the connection will lead to the compromise of the other.

High trust connections can be characterised by being:

• Unauthenticated,
• Executed with elevated or system level privileges irrespective of the user context,
• Unencrypted or merely obfuscated.

Such high trust connections are the common ‘out of the box’ configurations of many products. They are also significantly less complicated for developers or administrators to implement correctly and so paradoxically are less likely to have implementation security flaws. They are convenient.

As the trust level of a connection drops it requires security controls to be added to manage the increased risk of allowing the connection. These security controls could be:

• Network flow control,
• Authentication,
• Encryption,
• Maintained user context,
• Authorisation Permissions,
• Content Inspection.

Security controls are complex, costly, introduce latency and are usually poorly understood by developers and administrators. They are inconvenient.

There is always a tension between the security view of a system design and the other views held by the other system design specialisms. In a perfect world with a well-scoped, well funded, system delivery project with plenty of time to implement it is possible to consider the trust level of every connection and to design appropriate security controls for each connection in turn.

No project is ever like this.

In order to increase my coverage as a security architect I tend to use the following conceptual tools:

• Zones of trust,
• Connection patterns,
• Choke points.

These dramatically reduce the time I need to design and assure systems.

Zones of trust are a defined area of the system where by by necessity, by the presence of key information assets and by the wider environmental context the connections within the zone are treated as at the same level of trust. This effectively couples the components within that subsystem for security purposes.

Connection patterns outline the requirements for security controls on the connections within each zone of trust. These should aim to be focused more on the requirement (e.e transport encryption) than the technical solution (e.g. SSL) as there is always more than one way of doing things and product vendors won’t always choose the same one you have. These patterns have to consider the environmental context of the zone as a whole. For example are the components within the zone connected by dedicated switching fabric? and are they in a secure physical hosting environment?, if so then transport encryption may well be overkill.

Choke points are the interconnections between the zones of trust. These define the total interaction between different zones of trust and are the focus of my time on security controls. This is where I assure the strength of the security zones.

A key activity is to not only understand the functional flow of the system into and out of the zone of trust but also the non-functional-aspects such as:

• How is the zone managed?
• Where are the patches deployed from?
• Does the zone have dedicated switch fabric?
• Does the zone have dedicated virtual machine hosts?
• Is the zone in a locked rack?

Extensive (And expensive!) functional security designs can be easily subverted by a single administration laptop with access to all the zones of trust in the system.

Zones of trust is a key High-Level Design architectural view. It relies on re-using the logical views used by the other system designers in order to allow them to subsequently understand why I am asking them to inconvenience themselves with security controls.

Sometimes a zoned view is easy to identify through the design or discovery processes. Sometimes you need tools to tease out the subtleties you would not otherwise have seen. I will discuss some of the tools I have used in a future post.