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.