MFA, aka multifactor authentication – you know the drill. Enter password. Key in code from your authenticator app. Check your email and click on the link.
While these steps can be frustrating, we know that they keep us and our company safer. But what if you simply cannot do those steps? It’s a real situation, if you’re a machine (aka an application, program or script running in the cloud or data center) trying to access an API, SaaS service, or database.
MFA has gained popularity as an effective way to enhance security for human users. However, when it comes to securing machines and automated systems, MFA falls short in many ways. In this post, we’ll explore why this mode of authentication won’t work for machines. We’ll also propose alternative strategies, including policy-based access control and conditional access based on workload security posture, to safeguard our digital assets.
The Limitations of Multifactor Authentication for Machines
Multifactor authentication is a robust security measure for human users because it relies on something the user knows (a password), something the user has (a mobile device, smart card, or token), and something the user is (biometric data). These factors provide an additional layer of protection beyond a simple password. However, applying this approach to machines presents several challenges:
Machines Lack Cognitive Abilities
Machines, unlike humans, lack the cognitive abilities to understand and interact with the MFA process as humans do. They cannot enter a one-time passcode or use a biometric feature to authenticate themselves. Expecting machines to complete these steps is unrealistic. (And, if they can complete these steps the way a person does, we’ve got bigger problems in life.)
Complexity and Scalability
Managing MFA for a large number of machines can be complex and burdensome. Each machine would need unique credentials and a way to interact with the authentication process, which could be challenging to implement and maintain at scale.
Vulnerabilities in MFA Implementation
Even if it were possible to implement MFA for machines, it would introduce additional points of vulnerability. Just as with human MFA, there is always the risk of compromised tokens, intercepted one-time passcodes, or stolen biometric data.
In short, MFA for machines is somewhere between hard and very hard, with the operations complexity to match. Despite this, we know that the accelerating proliferation of machines needs a more secure approach than just another poorly managed secret.
A Better Approach: Secure Machine-to-Machine Communication
Instead of relying on MFA for machines, a more plausible approach is to focus on managing access from workload-to-workload, combined with basic hygiene for your environment. Let’s cover the more modern elements of securing workload access, followed by some of the basics.
1) Validate and Attest to the Identity of Your Workloads Before Every Connection Request
To ensure that a workload can connect to a sensitive database, a SaaS service, or an API, that workload should be able to provide evidence that it is who it says it is. As opposed to relying on Layer 3 technologies like mTLS to solely assess the network-related disposition of the asset, move up the stack to validate the identity of the workload itself – often referred to as attestation. This is particularly useful as your environment expands to include highly dynamic and cloud-native applications that move and scale automatically.
2) Institute Policy-Based Access Controls
Define strict, policy-based access policies that dictate which workloads or machines can communicate with each other and under what conditions. These policies can be based on factors such as workload identity, purpose, and location.
Policy-based access is often implemented alongside a move to short-lived access tokens, which in itself provides a higher level of security by ensuring limited time to access a resource before the token needs to be refreshed. This can significantly reduce dwell time if someone gains unauthorized access.
Finally, this enables your security team to quickly and easily switch allow/deny access on policies to enforce guardrails, react to security incidents, or run tabletop exercises.
3) Eliminate Hard-Coded Secrets
Secrets, which are the de-facto approach for workload-to-workload access, have a couple big problems. First, they imply that if you have the secret you are permitted to have access. That can be pretty far from the truth. Also, given that they are often hard-coded into applications or stored in environment variables, this sprawl increases the risk of a key being stolen. After it’s stolen, see issue No. 1. You get the idea.
Moving to identity- and policy-based access controls (Nos. 1 and 2 above) puts you in a strong position to move away from long-lived and hard-coded keys.
4) Embrace Conditional Access Based on Workload Security Posture
Implement conditional access controls that evaluate the security posture of workloads running on machines. This approach ensures that only workloads that meet predefined security criteria can access specific resources or communicate with other machines. For example, workloads with up-to-date security patches and robust security configurations may be granted broader access.
5) Deploy Network Micro-Segmentation
Segment your network to isolate machines based on their roles and access requirements. This limits the attack surface and reduces the risk of unauthorized access. Only allow essential communication pathways between trusted machines.
While this is a powerful tool to protect your applications, micro-segmentation can be complex to implement and even harder to maintain. As you move to highly dynamic cloud-native environments, it can become difficult to accurately maintain the least number of paths that should be open to an application. On the other hand, long-lived legacy environments often lack the appropriate logical or physical separation needed because the environment was developed well before micro-segmentation became a regular practice.
Furthermore, today’s environment workloads may also be connecting to SaaS services or third-party APIs. Microsegmentation doesn’t really apply here, given that you cannot control someone else’s network.
Machine Security Basics
And now for a few of the basics (that we know you do, but we couldn’t in good conscience write this article and ignore them):
1) Monitor and Detect Anomalies
Implement robust monitoring and anomaly detection systems to identify suspicious behavior or unauthorized access attempts. A bonus: If you have implemented policy-based access control described above, you likely have (or can create) a centralized, homogeneous log source to track access attempts efficiently, versus combing through the logs of each individual application. This log source will give you a more efficient way to run identity-based threat detection and response against workloads.
2) Regularly Update and Manage Patches
Keep all machines and software up to date with the latest security fixes. Vulnerabilities can be exploited by attackers if systems are not properly maintained. Run an endpoint agent on machines and/or a cloud security product to regularly scan for security gaps or misconfigurations.
3) Implement Encryption
Encrypt data in transit and at rest to protect it from interception and unauthorized access. Modern encryption algorithms and protocols can provide a high level of security for machine-to-machine communication.
While MFA is a valuable tool for securing human access to systems and data, it is not a practical solution for securing machines. Machines require a different set of security measures that focus on the integrity and confidentiality of the communication between them, including policy-based access control and conditional access based on workload security posture. By implementing these robust authentication, encryption, monitoring, and access control strategies, we can better protect our digital infrastructure from machine-level threats in an increasingly interconnected world.