One of the many effects of the COVID-19 pandemic is a change in people’s shopping habits. With the massive shift to shopping online came a parallel increase in Internet fraud, including attempts to scam consumers out of sensitive personal information, impersonate businesses by using stolen credentials, break into consumer devices and networks to obtain access to sensitive data, and hold systems and data ransom.
Apart from exercising secure behavior online (strong passwords, avoiding suspicious forms of payment, etc.), it is also important to examine website trust indicators. For years, Internet users were told to “look for the lock” to know that a website was secure. In 2019, several browsers extended this by changing how they display legitimate sites. Click on the padlock to view the certificate information and organization details, and forget sites that fail to encrypt data transmissions using TLS—Transport Layer Security, formerly known as Secure Sockets Layer, or SSL.
As companies and organizations offer more online services and transactions, Internet security becomes critical to ensure that sensitive information—such as credit card numbers—is transmitted only to legitimate businesses. This means organizations must add TLS support to their websites, which requires acquisition and use of digital certificates.
But there is a lot of confusion when it comes to certificates and establishing trust. Adequate machine identity management is crucial to get out front on trust with your customers. Here's what your team needs to know.
What is machine identity management?
Enterprises spend billions of dollars each year on identity and access management, most of it to protect digital human identities—usernames and passwords. Not much gets spent on protecting machine identities, even though our entire digital economy hinges on secure communication between machines. Machines are driving unprecedented improvements in business efficiency, productivity, agility, and speed, but they do not work in isolation, since they need to be communicating with other machines.
Before machines can communicate securely, they need some way to determine if the other machine is trustworthy. When online, humans rely on usernames and passwords to identify and authenticate themselves to machines. Machines also have digital identities, but they do not rely on usernames and passwords for identification and authentication. Instead they rely on digital certificates and cryptographic keys that serve as machine identities.
How TLS certificates make machine identities work
At the beginning of every communication, machines check these certificates as digital identities to establish trust, authenticate other machines, and enable encrypted communication. TLS certificates are digital passports that provide authentication to protect the confidentiality and integrity of website communication with browsers.
The TLS certificate's job is to enable secure sessions with user browsers via the TLS protocol. This secure connection cannot be established without a digital certificate, which connects company information to a cryptographic key.
The following is a high-level diagram of how TLS connections work:
The problem: Self-signed certificates
Certificates are normally obtained from a certificate authority, or CA: a trusted company that provides certificates and that participate in a chain of trust that allows end-user browsers to validate that the certificate is indeed trustworthy.
Companies can also create self-signed certificates, without going to a CA. The industry has long debated the benefits and risks of using self-signed certificates. Understanding this debate requires establishing a baseline understanding of why certificates exist. The usual misunderstanding is that certificates exist to perform encryption; this is incorrect. Certificates exist to prove identity. Cryptographic keys are a means by which they do so, and once the identity is established between two parties, encryption is then used to exchange information securely between them.
For example, Amazon.com’s TLS certificate is not there to encrypt your data; it is there to prove that you are sending sensitive data to the actual Amazon.com, and not to an imposter. Encryption is the means by which that happens, but the encryption itself is pointless if the data is going to the wrong entity.
Identity is why certificates exist. As a means of proving identity, a self-signed certificate is like having a homemade passport—nobody should trust it. The identity of Entity A can only be proved to Entity B by means of a third-party verifier, Entity C, whom Entity A and B both trust. The third-party verifier cannot also be Entity A (“Trust me! I am who I assert myself to be!”).
A lot of enterprises believe that self-signed certificates are primarily useful in test environments, but even then, they are a poor idea because they do not allow testing the real scenario. For one, they are not testing the ability to use certificates that actually have any trust associated with them, and important test scenarios such as certificate revocation list (CRL) validations will be skipped, since they do not apply to self-signed certificates. On top of that, this practice could easily get propagated to production systems.
Many enterprises also believe it is okay to use self-signed certificates on internal sites such as employee portals, even though doing so results in browser warnings. Organizations typically advise employees to simply ignore the warnings, since they know the internal site is safe. This can encourage dangerous public browsing behavior: employees accustomed to ignoring warnings on internal sites may be inclined to ignore warnings on public sites as well, leaving them, and the organization, vulnerable to malware and other threats.
Know who to trust
Major breaches have happened where exfiltration of data through encrypted tunnels using self-signed certificates went undetected because it looked like regular and legitimate traffic. Several malware and banking Trojans use self-signed certificates that trick users into downloading malicious code; cyber‑criminals also use self-signed certificates to conduct man-in-the-middle (MITM) attacks to impersonate banking, e-commerce, and social media websites.
Once compromised, a self-signed certificate poses further risks: an attacker who has already gained access to a system can spoof the identity of the victim. Organizations also cannot revoke self-signed certificates, and must instead replace or rotate them, which cannot be done rapidly.
Attackers are exploiting self-signed certificate use, so enterprises should stop using them unless they are used between components or services residing within the same machine—implying “I am who I assert myself to be” is valid when I only have to trust myself.
Keep learning
Get up to speed on unstructured data security with TechBeacon's Guide. Plus: Get the Forrester Wave for Unstructured Data Security Flatforms, Q2 2021.
Join this discussion about how to break the Ground Hog Day repetition with better data management capabilities.
Learn how to accelerate your analytics securely into the cloud in this Webinar.
Find out more about cloud security and privacy, and selecting the right encryption and key management in TechBeacon's Guide.
Learn to appreciate the art of data protection and go behind the privacy shield in this Webinar.
Dive into the new laws with TechBeacon's guide to GDPR and CCPA.
