Trust is a vulnerability. Protecting the network perimeter and trusting authenticated users is being replaced by a new paradigm where you trust nothing and verify everything. Welcome to Zero Trust.
Castles and Moats
The traditional cyber security model has been likened to a castle and moat. You bring all of your valuable assets inside the fortified walls, and you regulate access with a portcullis, a drawbridge, and a moat.
If someone wants to enter the castle they have to have a conversation with the guards in the gatehouse. If the individual is recognized as someone who should be allowed inside, the drawbridge is lowered, the portcullis is raised, and they are permitted to enter. If they are unrecognized but possess a token vouching for them such as a scroll bearing the signature and official seal of a trusted nobleman they will be allowed in. An unknown with no means to identify themselves is left outside.
With a network, you have your precious network assets inside your firewalls and other digital fortifications. Connections to the network are only permitted after a conversation between the device that wants to connect and the authentication services of the network. An ID and password pair have to travel between them. If the credentials are accepted, access is granted and they are allowed within the perimeter. Obviously, today your perimeter has extended to include your cloud assets.
The person you’ve just admitted may have bona fide credentials, but they might still have malicious intent. And they now have the run of the castle. Or the network.
With Zero Trust you don’t authenticate once then trust for the duration of the connection. The honed-down Zero Trust maxim is “never trust, always verify.” And you keep verifying even when the visitor—regardless of how frequently they visit—has been allowed inside your perimeter.
Zero Trust
Zero Trust is generally considered to have been birthed in 2010 when John Kindervag gave a talk at a conference and subsequently released a series of papers.
The core concept of Zero Trust is that organizations should never automatically trust anything inside or outside the network. That is, don’t automatically trust someone trying to get inside, and don’t trust anyone just because they are inside. Zero Trust is built on technology, topology, and governance. Many of the technologies have been around for a long time.
The first consideration is user identification and authentication. It goes deeper than an ID and a strong password. Multi-factor authentication (MFA) is the norm. Passwordless authentication using standards such as FIDO2 can also be used. And the identification also includes the device the user is accessing the network from. Is it their usual corporate device, from within the network? Is it a corporate laptop from outside the perimeter? Or is it a personal device? Is the IP address it is connecting from one that has been seen before?
IT Governance comes into play here. You define what behavior you’re going to allow. Can someone use a personal device from outside the network, or only inside the network, or neither? Or perhaps staff can use them inside the network but they are limited to read-only access.
Together, the user and the device are awarded a value, something like a security score. It dictates what this user session is capable of, according to the role and privileges of the user and the company’s knowledge, experience, and confidence in the device. If the device is a well-known computing device listed in the IT asset register and the operating system is patched up to date and the end-point protection has the latest signatures, it’ll be treated very differently than an unrecognized personal tablet connecting from a hitherto unseen IP address.
The second consideration is the network design. A flat network topology is like an open-plan office. Anyone can stray anywhere. A flat network is too easy to laterally traverse and explore. Network segmentation—even to the point of micro-segmentation—using next-generation switches and firewalls will provide granular access controls to restrict access to sensitive or valuable data or assets. Only those users with legitimate access rights—and a verified device—will be able to access the various network segments.
The third consideration is application-level control. Who can access the different software and services you have on your network? Based on the network segment the application is hosted in, and the user and device score, you can grant or remove permission for users to run or use particular software packages.
With Zero Trust you provide controls and protections as close to the asset you’re protecting as possible. You design your network and its segmentation and protection requirements from the inside-out, not the outside-in.
Commercial software is available to make it easier to achieve this level of granular control and user and device authentication. These provide invaluable reporting, monitoring, and alerting that can be customized to react to different events and triggers such as device hardware type, firmware level, operating system versions, patch levels, and security incident detections.
Implementing Zero Trust
Implementing a Zero Trust Architecture (ZTA) on an existing corporate network is best achieved by phasing it in as part of your overall digital transformation strategy. Trying to retro-fit an entire ZTA onto an existing corporate network big-bang style isn’t going to end well.
An ideal opportunity is when you are planning a cloud migration. You can view the cloud as a greenfield site and implement the layers of the ZTA before you move your line of business operations to the cloud.
Understand Your Network, Assets, and Data Flows
Map your network thoroughly. That includes the current topology and all of the network-connected devices. This is going to require an asset discovery phase. There are software tools that can help you with this, but it usually involves some floor-walking, clambering about in server rooms and cupboards, and crawling under desks. Don’t forget assets that are in the homes of staff.
You also need to understand the data, applications, and services that the users of the devices access.
You’re now in a position where you can perform a risk analysis. If the risks cannot be mitigated using a ZTA you may need to retain some of your existing security controls until you can reorganize your workflows or topology in a way that allows the ZTA to provide sufficient protection when later phases of your digital transformation are implemented.
Build From Identity Outwards
There’s a saying that with Zero Trust, identity is the new perimeter. So identity must be managed and securely controlled. The principles of least permission should be followed so that a user has the permissions they need to fulfill their role and nothing more. Users must never share account credentials.
An Identity and Access Management (IAM) system that is compatible with internal and external services will provide a single, central, secure source of identity verification. An IAM system that can federate with external systems used by third-parties who might need to access your network periodically may be advantageous to you.
Applications and devices—including Internet of Things devices—should be allocated their own identities with the minimum privileges required for them to operate. Applications and services can use certificate-based authentication to permit connections with other software platforms, for example.
Leverage Health Information
Device identity will be used with challenge and response conversations regarding the security state of the device—including the patch state of applications and the operating system, the presence and state of end-point protection—and the identity of the user to decide what the device is allowed to do. Deeper challenges can be posed to the device, checking on items such as the firmware version and the device’s boot process.
The user associated with the device can also be given a health score. Are they connecting from an unknown IP address that suggests a geographical anomaly? Are they trying to connect at three in the morning?
Rules and policies that you create within your Zero Trust management platform will determine what the user can do.
Trust is a Vulnerability
In Zero Trust networks, everything is considered hostile and all connections that access data or services should be authenticated. User access is controlled using multi-factor authentication or key-based password-less systems and an Identity and Access Management system.
Extra authentication will be requested when the user wants to access sensitive or valuable data or other assets. But this doesn’t mean the user experience has to be bad. In fact, with a physical key or fob-based system, it can actually improve.
Services and applications can authenticate via API calls or using a public key infrastructure.
Protect Devices, Users, and Services
Zero Trust means trusting nothing, not even your own network. Your devices need to be protected from threats that might exist within your own network. You’ll still need to use end-point protection software to defend against viruses and other malware, and authenticated, encrypted protocols such as Transport Layer Security (TLS) should be used to access foundational network services such as the Domain Name Service (DNS).
Basic cyber hygiene such as monitoring the network for unauthorized devices or inexplicable behavior should continue, and security patch regimes should be maintained.
Because you invested the effort to map your network and determine the devices, applications, and services that users will require access to, your Zero Trust monitoring can use that information to detect attempted violations of the rules that you have put in place.
Use Commercial Offerings and standards
Use software, services, platforms, and providers who already support Zero Trust. Trying to build your own supporting infrastructure should be avoided due to the cost, complexity, and potential for error.
The standard cyber security mantra of using tools, products, and services designed and developed by specialist professionals holds true.
Whenever possible, use standards-based solutions. You’ll get easier interoperability between devices and services, and it simplifies federation between external systems you may wish to connect and interact with, such as those provided by your cloud provider.