Implementing Zero Trust with Osirium products

Implementing Zero Trust Without Impacting Your Business

Zero Trust means that we should not trust any system, user, application, or API without proof of their identity and authorisation. IP addresses or originating network are no longer sufficient proof of identity.

Since there are no perimeters, you cannot assume that a firewall is providing any protection. Zero Trust takes the position that you should assume that every system you have is connected directly to the Internet and should protect itself.

This is of course an unattainable ideal - but a very valuable set of principles. You can find these in depth in NIST 800-207.

Over the years we have seen so many data breaches, ransoms and malware attacks. Zero Trust principles properly target the root causes, which is why it is such a valuable framework.

So, where's the problems if we can see the solution? Here we break down the barriers to achieving zero trust, later we will show practical routes to deal with these.

Scale

If every moving part of an IT solution has to verify the identity and authorisation of every other part no real work would ever get done!

We could find ourselves subdividing every API call down to the function level -and therefore the security overhead would overwhelm the real work. We would also find that we would not be able to analyse and reason over all the granular policy required.

‍

This is why Zero Trust has the concept of Boundaries or Micro-Boundaries. Where these boundaries are set will make a huge difference in security. For example if we set the boundary to the organisation - we will have no effective security.

Identity Everywhere

Zero Trust requires that everything have a verifiable identity. For any organisation this quickly becomes unwieldy. Most organisations struggle to know how many systems they have and how many systems they use that do not belong to them.

All organisations rely on third parties - which means many people and systems that are not part of their known inventory. The obvious solution is that the third parties should have their own identity providers and that organisations should be able to verify their third party users against these.

Trust

Trust in systems/APIs/applications comes from certificates - and a full Zero Trust implementation will have a lot of these! Certificate life-cycle management is a significant overhead. It's a specialised job, particularly for organisations with a wide range of systems.

Trust in people comes from identity providers, and is really enhanced by multi-factor authentication. For people authentication is the equivalent of identity. Authorisation is seen as separate from Authentication.

Legacy Systems

The main issue here is who is calling the system legacy. What the CISO calls legacy, the rest of the organisation sees as an asset that has not yet earnt its keep. Good examples include medical equipment such as MRI scanners, manufacturing equipment such as CNC systems and all manner of physical and electrical test systems. This kit may cost millions and have an expected operating life of 10-30+ years.

The upshot is that the working life is much longer than the life of an operating system, let alone a major revision of an operating system.

We need to be very clear that legacy systems pick up vulnerabilities as they get older. This is because our adversaries have more time to study these systems.

Equipment will often out-live their operating systems but will need to provide service - even with known vulnerabilities. Later we will outline micro-boundaries (or micro segmentation) to address this.

Zero Trust and Privileged Endpoint Management

Being able to trust the operating systems in your end-points is a key part of Zero Trust. Privileged Endpoint Management (PEM) means that your users cannot run elevated processes without permission - this gives you control of what is an is not installed on your endpoints. Most malware needs to run elevated to get a real hold or to snoop on network or keyboard channels.

Given that virtually all commercial software is signed, and that most open source software publish checksums, PEM is ideally placed to verify the identity of your applications.

You could go a stage further in issuing client certificates to your Windows workstations.

Zero Trust and Privileged Access Management

This gets to the real heart of Zero Trust - separating the authentication from the authorisation. Privileged Access Management (PAM) authenticates against a variety of sources. Active Directory is the most common, followed by a number of multi-factor authentication providers. SAML is an option, and this too can use MFA.

Authorisation is through Profiles - a Profile defines which users can access which system at which privilege, when. It will also define workflow options such as approval and if the session will be recorded.

The PAM server can also support applications installed on a MAP (Mapped Application) Server. You can consider this as a secure, controlled environment workstation where you can host legacy or complex applications. For example, if an application has dependencies with known vulnerabilities, the MAP server can be configured such that it cannot access the Internet.

Since the PAM server, and indeed MAP servers can have multiple network interfaces, they can have connections into protected network segments. This approach creates boundaries or micro segments. On the micro-segment we can place all the systems and equipment we need for a particular function.

Imagine that we have an electron microscope that is both perfectly functional but has a Windows XP viewing station. We can place these onto their own network alongwith a small firewall to block any outbound traffic. We can use a number of strategies for moving data from this micro segment (micro-boundary) to general networking. We could use a firewall rule for user driven transfers, or we could use an application on a MAP server that has interfaces to both networks.

In the next section we will show you an automated approach.

Zero Trust and Privileged Process Automation

This is the ultimate separation of users from systems, in fact there is no direct system access at all, users need not have accounts on systems. With Osirium Automation, business processes are run in specially secured containers. Users interact with these processes through a web projected UI. The processes collect any credentials they need from the PAM system.

Once again, you can see how Privileged Process Automation (PPA) plays into the micro-segmentation approach for legacy systems in Zero Trust.

Summing up

The Osirium products help protect the endpoint, separate users from privileged credentials and automate privileged processes. They all contribute to a Zero Trust architecture by verifying identities and separating authentication from authorisation. And whilst they can help prevent malware getting a hold or moving laterally you should always use anti-malware, since it is the right tool for the job.

When using the Osirium product suite to deliver on Zero Trust Policies are easy define, review and reason over in the future. In particular, policies around legacy systems are simple and easy to work with.

As always, if you'd like to know more - please get in touch.