Every year for the last 18 years, my spouse and I have driven across the country to visit her family for Christmas. And every year for at least the past 10 or so years, one of our credit cards is frozen.
Although it’s a pain in the you-know-what, I understand why it happens. I live in Los Angeles, so I’m unlikely to be buying $100 in food and supplies at a Walmart in Abilene, Texas. And frankly, I’d rather make that phone call telling my bank that the purchase wasn’t fraudulent and to unfreeze my card than discover weeks later that an identity thief stole my information and took a cross-country spending trip.
So, I was surprised to discover that TLS authentication, the protocol used to validate the identities of websites to the user accessing them, does not, by default, require clients or end users to validate their identities. Like its predecessor SSL, TLS uses an X.509 certificate to verify and authenticate the identity of a website or host. But apparently, those end users don’t have to authenticate themselves back to the server!
Human identity and access management (IAM) provider OneLogin explains why in its SSL/TLS Mutual Authentication Primer:
“Web server authentication is easily implemented and sufficient for establishing an SSL connection while requiring users to install X.509 client certificates is prohibitively expensive and difficult for general [i]nternet use.”
In itself, I guess it makes sense. It’s not easy to use so we don’t require it. But in this age when the term machine means everything from traditional physical servers to short-lived containers—and of course, websites and all their components—shouldn’t this issue be addressed?
Before coming to Venafi, I wrote a lot about IAM, and I remember how several solutions talked about their ability to doublecheck a person’s identity, mainly to prevent access from someone with a valid name and password if other [things] seemed off. For example, if Bob Vance of Salt Lake City normally logs into his workstation from Salt Lake City between 9 AM and 8 PM MST and occasionally logs into the corporate network from London where the company has an office, he logs in, no problem.
But if Bob logs in from a mobile device located in Latvia at 2 AM MST, the IAM solution will prevent his credentials from gaining access even if those credentials are correct. It’s a similar scenario to my credit card experiences. If the real Bob in fact is in Latvia, the inconvenience of calling his IT department and letting them know is well worth avoiding the risk that some unknown threat actor is spoofing his credentials in the hopes of gaining personal records or intellectual property.
But as we’ve discussed on this blog, machine identities are outpacing human identities to a ridiculous rate. A medium-sized organization in 2018 can have tens of thousands and even hundreds of thousands of machines, all of which need to have their own credentials to be trustworthy enough to access the network, let alone any machines from the outside trying to communicate.
And as we’ve discussed in this blog many times, cybercriminals increasingly are leveraging SSL/TLS vulnerabilities to mask their attacks, and this neglect of the client side of the equation seems like a gift to these bad actors. It may even partially explain analysts’ predictions back in early 2017 that 50–70 percent of network attacks “will use seemingly trusted SSL to infiltrate, expand, and exfiltrate in the very near future,” as Venafi’s Scott Carter writes.
That percentage is frightening and most likely will grow. And why wouldn’t it without protecting servers from potential malicious clients? After all, consider the economies of scale. It’s much easier to automate machines to do your dirty work than have to phish for human identities to get the job done. What’s to stop a bunch of seemingly innocuous client machines from attacking your network with your own machines’ blessing? Especially when, according to Forrester Research, enterprises, on average, are tracking less than 50 percent of potential machine identities that communicate with the networks?
Kevin Bocek, vice president of security strategy and threat intelligence at Venafi, explains, “Almost all security systems were architected in the days when encrypted SSL/TLS made up small portions of network traffic. At that time SSL/TLS wasn’t being abused by attackers.” They simply were not engineered to inspect encrypted traffic. As a result, many of these solutions suffer from the inability to safely access an enterprise’s keys and certificates to inspect traffic safely. According to Bocek, “This must be a high priority for the entire security industry. Right now, our adversaries continue to win.”
But even if you are unsure how to implement mTLS, you can still do several things to minimize the impact malicious client machines could have on your network. To manage the complexity of the growing number of machine identities accessing your network, consider a solution that can make an inventory of those machines and that can leverage the powers of automation to quickly cull out any machine identities—client or server—that read as suspicious.
In the meantime, how do you think implementing mTLS could help lower the number of attacks using TLS encryption?