Building Zero Trust
When you think of zero trust, you tend to think of network segmentation. Creating communities of interest (COI’s) and segmenting servers away from each other to prevent lateral movement within one’s network. Network segmentation is just the first step in a zero-trust model. Others include authentication, segregation of duties, and cryptographic certificates. Though all are important, authentication is a difficult one to get right.
Secure Shell, or SSH, is an authentication mechanism used for remote connectivity mainly to UNIX and Linux based operating systems. SSH creates a secure, encrypted, connection between the administrator’s endpoint to a server. Though SSH is heavily used for connectivity it does have one major flaw, you must trust the certificate presented to you upon the first login. Trust On First Use, or TOFU, requires the administrator to initially trust the server they are connecting to without knowing the validity of the certificates being presented. Once trust is given to an unknown certificate, the administrator is allowed to continue with their username and password.
Trust On First Use
TOFU is nothing new in terms of security and is widely used throughout information technology. Take for instance setting up a new firewall or other types of security appliances. Security appliances are designed to encrypt administrative connections to the management plane. Most, if not all major players use self-signed certificates in order to encrypt that communication. This is another example of TOFU where a firewall administrator must first accept an unknown security certificate prior to being allowed to connect to the device. Accepting unknown, or unverified, TLS certificates are something we tell end users not to do all the time. So why is it Ok for us to do so? How do we know whether our connections are trusted and not being compromised by a man in the middle attack?
How Do I Trust My Connections?
Unfortunately, there is no easy answer to this question. Systems are designed to create new private and public certificates upon installation. This is to ensure that no two private certificates are identical and not re-used between systems. When these certificates are generated for the first time, an administrator has no other option but to trust the certificate being handed out.
Cryptographically signing certificates is one such way that could be used to overcome this problem. This is performed on software package installation and patching. Microsoft, Red Hat, Ubuntu, and Apple all cryptographically sign their software. This prevents the operating system from installing applications that could have been created by a malicious user, potentially infecting one’s machine.
Organizations can perform the same level of trust for authentication. Creating an internal Public Key Infrastructure, or PKI, can reduce that uncertainty. PKI’s can provide validity in those connections as one has to first trust the root certificate authority. Once trust has been established, certificates generated and signed by the root certificate authority will also be trusted by the system. Though getting it right the first time might seem to be difficult. Once established, it can prove to be one of the best assets security professionals have in their arsenal.