Picture this scenario: Your marketing team wants to create a microsite for a new campaign, and because of time constraints, someone on the team decides to use a wild-card certificate and doesn’t tell IT. Several months later – with the campaign going strong – the wild-card certificate expires, and the microsite goes down. In a panic, the marketing team reaches out to IT asking what they did to make the site go down and insists that it be fixed ASAP.
Do you consider this an insider threat? Generally, when we say, “insider threat,” we mean a malicious actor within the company, such as Edward Snowden, the NSA contractor who used SSH keys to access confidential government files. The insider threat, though, is much broader; it includes employees, contractors and partners who can unintentionally put the organization at risk. The wild-card scenario I just described is a classic example. When protecting against insider threats, we must protect against every one of them—from the malicious to the innocent—because both introduce risk.
Digital certificates are important security assets that identify and authenticate machines. Like usernames and passwords for human identities and access management, digital certificates and cryptographic keys protect automated machine-to-machine connections and communications. And they can suffer a wide range of misuse – from their malicious use in attacks to unmanaged, ad hoc use that can result in an outage or other vulnerability.
Preventive measures, then root-cause analysis
I’m guessing that, in the wild-card example, your initial focus would be on finding the source of this outage so that you could get your site back online as quickly as possible. You would probably think through all the potential root causes for this kind of failure, which could be anything from a line of code among millions to a vulnerability somewhere else on your network. You’d probably need hours, even days, to troubleshoot it. Would you have the tools and time to investigate the cause?
Once you’ve identified the problem as an expired wild-card certificate and resolved the incident, how do you ensure this doesn’t happen to you again? Would you try to educate everyone in the company on best practices for key and certificate usage? That’s not a bad idea, but it’s often not practical—and still wouldn’t ensure proper usage. After all, much of the reason that username and password credentials receive so much attention in our industry stems from the (relatively) old saying that humans are considered the weakest link within a company’s security posture.
I think we have the whole “find the root cause” thing backward. Of course, it’s important to figure out the root cause of a failure. By determining the cause, you can use that information to set up processes and deploy technologies to ward off a similar failure that could impact your company in the future. However, doing so should take place after the fact, when your team has time to research it. Finding the root cause should not be part of your incident response plan. That’s a reactive way of handling these incidents and is oftentimes an inefficient use of resources.
Instead, our first goal as security professionals should be to focus on prevention. And when it comes to the misuse of keys and certificates—whether from insider threats or external attacks—machine identity protection is the most effective strategy you can use to prevent these threats and reduce overall risk.
The importance of machine identities
You’ll need to monitor the identities of all the machines that are either on or connect to your network. And by machines, I don’t just mean physical machines. In addition to physical servers, routers, laptops and mobile devices, your definition of machines needing protected identities should also encompass virtual machines, IoT devices, APIs, algorithms and applications, including security technology and mobile apps.
If your mind isn’t reeling at the number of identities you need to both manage and secure, it should be. The number of entities on corporate networks that need to communicate securely is skyrocketing. So why is it so important to give them all identities, let alone to secure and monitor each of those identities, especially when they all change so quickly?
When machines on your corporate network communicate, they pose risks just by connecting. Machine identities help manage these risks by identifying and authenticating each machine to determine if it’s trustworthy. These identities are used to authorize the flow of data to trusted machines and prevent the flow of data to untrusted machines. Without a strong machine identity protection program, you can’t control the flow of data going in and out of your networks.
If you lack machine identity protection, odds are you won’t detect when a machine is compromised until you experience something consequential, such as a massive outage. You won’t detect unauthorized data exfiltration, even if terabytes of your most sensitive data are leaked. And these things can happen easily without bad guys getting access to employee credentials. If cybercriminals can take advantage of a weak or vulnerable machine identity, they can tunnel in, look for other vulnerabilities to exploit and use them to pivot across your internal network.
Unlike the usernames and passwords that serve as human identities, machine identity protection requires you to actively manage a vast inventory of keys and certificates. And these machine identities generally provide higher-level access than most human identities. Even if we put privileged access aside, you still need machine identity protection to ensure that your other security technologies – such as SSL inspection or web application firewalls (WAFs) – are functioning properly. Without machine identity protection providing quick, safe access to keys and certificates, you may be limiting the value you can get from other security investments that use machine identities.
The real meaning of ‘low man on the totem pole’
When most people think of “low man on the totem pole,” they think of the least important person or thing relative to its competition. But the phrase is a misnomer. The Native American tribes that build totem poles consider the base to be the most important element. While apprentice carvers may work on the higher levels of a totem pole, only a master carver works on the base. After all, that foundation tells the most important piece of the story.
By protecting machine-to-machine communication, you can help stop a wide variety of security threats, including many insider threats, before they can damage your network and your company as a whole. In fact, I consider machine identity protection to be the low man on the totem pole for two primary reasons:
Machine identity protection is the foundation on which other layers of security are managed.
Identity and access – both humans and machines – are essential to protecting critical systems and data.
However, this is easier said than done. Machine identities are poorly understood, and therefore, weakly protected. And the numbers show that unlike human identity protection—which organizations already spend billions of dollars on each year – most companies spend almost nothing on machine identity protection. Without strong machine identity protection at the base, we’re tipping the totem pole.
Machine identity protection: As important as human identity protection
We all know that human identity access management is important, which is why we assiduously protect usernames, passwords, biometrics and two-factor authentication mechanisms. But compare this to machine identity protection. Why would you let a terminated employee walk off with access to an SSH key without deactivating it? Why would you allow some random guy on the marketing team to provision wild-card certificates for any number of microsites without any oversight? And why would you let TLS certificates, no matter who provisioned them, expire unexpectedly, causing a completely preventable outage?
Like human identity protection, machine identity protection should be one of the foundations of your security posture. Enforceable policies can prevent the misuse of machine identities—either by innocent insiders or malicious actors (inside or out). Another option is to set up self-service capabilities that can enforce strong machine identity policies across the board. This is a great way to provide machine identity services across the company—even to the impatient marketing team—while ensuring safe use of keys and certificates. Above and beyond that, visibility across machine identities companywide can prevent certificate-related outages or rogue use of keys and certificates.
Machine identity protection anticipates insider threats – and stops them
We need to stop taking a reactive approach to machine identity protection. Think back to our scenario at the beginning of this article. You focused on a symptom – the outage – went looking for the root cause (rogue wild-card certificate), and then solved the problem. Instead, what could you have done to prevent this from happening in the first place?
By nature, your security needs to be proactive. Otherwise, you can’t anticipate potential risks and prevent them before incidents occur or remediate them without having to go on a wild goose chase. When machine identity protection is built within your security foundation, it provides the visibility, intelligence and automation capabilities needed to minimize insider threats – and so many other threats caused by a breakdown in the security around your ever-expanding number of machines.