Exposure Reduction Guideline

Achieving a secure infrastructure is a serious undertaking, costing non-trivial time and resources. The cost to value ratio of any decision and mechanism has to be heavily considered before they could be implemented. This guideline provides opinionated recommendations on: which property of the infrastructure to focus on primarily for exposure reduction; an all-too theoretical approach to optimizing that property, and finally two technical measures for solving parts of the situation.

Priority #1: Infrastructure Exposure & Optimizing it in Theory

Even though you might not be familiar with Exposure, the term Attack Surface is probably not alien to you. Now if you isolate the social, psychological and humane aspects of Attack Surface, you are left with purely technical subset, which is exactly Infrastructure Exposure.

Why should I care about exposure?

Contact surfaces

Contact surfaces can be defined on a per-device-per-service basis, but are most often generalizable to machines with similar "missions". Defining contact surfaces means defining outside entity groups, inside which all entities have the same set of attributes.
The first attribute to consider is the need-to-reach: whether an entity should be able to communicate with the machine. This attribute divides all entities into two sets: wanted & unwanted.

The entities must be further attributed with trust: entities are either untrusted or slightly-trusted. Untrusted entities are those which we do not know anything about, while slightly trusted are either part of the intranet (including those that can connect via VPN), owned or used by an authorized personnel, ...

Based on these attributes different technical opportunities arise to secure the contact surfaces, at least in theory. Unwanted entities should be isolated from the subjects on the network, while trust-based differentiation should be done in the service.

Exposure in Practice

While in theory the optional mechanisms of exposure limitation are straightforward, in practice the dynamic nature and complexity of networks & infra will "throw forks" into the process. Network appliances, firewalls are not armed with enough processing power to keep separate sets of rules for each contact surface. Therefore, machines that are similar in contact surfaces should be put into subnets, therefore contact surfaces can be - at least partially - secured on the subnet borders.

The contact surface for unwanted & untrusted entities overlaps for most of the machines, or rather it is a good idea to manage it at the infrastructure perimeter via network reachability =~ firewalls. Generally you want to disallow any reachability on this surface and use exceptions when needed. For a university, we have compiled the following list of meaningful exceptions with use-cases:

Possible untrusted accesses by machine MISSION

For the other contact surfaces, governance via network reachability is a possible solution. When many contact surfaces overlap, aggregations over machines and the entities into (virtual)subnets might be available. The engineering of these subnets, the aggregation is a tedious work, and it heavily depends on the usage and design of the infrastructure. Therefore, we won't provide any generic advice here.

In cases where governance via network reachability between subnets fails, we have to look at the machines and the services themselves. There are too many services to aid you in securing all of them, so we chose the SSH protocol (as the most used representant in remote management services) on which we show you some general principles and some protocol-specific configurations to make it as secure as possible.

Exposure Reduction for SSH & Securing SSH

Depending on the particular state & needs, reducing exposure for SSH might be a different process for every infrastructure, however there are common points for many:

1. If SSH is not needed to be reached on a machine by anyone, it should be disabled.
2. If wanted entities are easy to aggregate into a few subnets, network or host firewalls should be set up.
3. Configure SSH in a secure way, that withstands intentional attacks by either insider threats or compromised slightly-trusted entities. Follow the recommended SSHD Configuration primer (below)
4. Use SSHs' authentication scheme to govern the contact surface via users and public key cryptography.
5. For very complex or voluminous networks, implement the bastion security principle.

SSHD configuration primer

Bastion

The bastion principle means placing an intermediary entrypoint into the infrastructure to handle governing multiple contact surfaces for all machines providing the same service. Then, reachability is between the machines and the bastion, and the bastion and the outside entities. This way, the bastion aggregates all machines under one IP address, and can aggregate the wanted entities for all protected machines.

Further contact surfaces are then managed via the bastion host itself, in a centralized manner. It provides an authentication & authorization interface that can be independent of network identificators, might support Role-based access control (RBAC) and aggregate outside entities of matching contact surfaces into groups. Furthermore, it provides heavy accounting capabilities.

Implementing bastions is a fragile and tedious process. Fortunately, some out-of-the-box solutions exist, such as the open-source Bastion from OVH, the partially open-source teleport from Gravitational or HashiCorp Boundary.