One of the many effects of the COVID-19 pandemic is a change in folks’ shopping habits. First we saw
panic hoarding of essentials, followed by a shift to online orders and deliveries. A recent survey
conducted by Agility PR Solutions on virus consumer impact found that 30 percent of respondents are
shopping less frequently in-store, and 21 percent say they are shopping more frequently online.

Concomitant with the shift to shopping online is increasing Internet fraud: attempts to scam consumers
out of sensitive personal information; to impersonate businesses using stolen credentials; to break into
consumer devices and networks to obtain access to sensitive data; and holding systems and data
ransom.

Apart from exercising secure behavior online (not sharing more information than necessary, using strong
[long] passwords, avoiding suspicious forms of payment, treating online deals with suspicion and
preventing phishing, not clicking on attachments from unknown sources, keeping systems updated with
latest software patches, etc.), it is also important to examine website trust indicators. This means
checking to verify that websites are legitimate. 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. Consumers can look beyond the lock by clicking on the padlock to view the
certificate information and organization details. At the very least, do not use 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.

What is Machine Identity Management?

Enterprises spend billions 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, as 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.

TLS Certificates

At the beginning of every secure 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:

Issue with Self-Signed Certificates

Certificates are normally obtained from a Certificate Authority, or CA: a trusted company that provides
certificates, and who 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. To understand this debate, requires establishing a
baseline understanding of why certificates exist. The usual (mis)understanding is that certificates exist to
perform encryption; this is incorrect. Encryption is not why certificates exist. 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 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 proven 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 that, this practice could easily get propagated to production systems.
Many enterprises also believe it is OK 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.

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.

Articles

Home

Key and Secrets Management

Bring Your Own Key

Exploring Cloud Service Providers' Crypto and Key Management Services

Importance and Advantages of Format Preserving Data Protection

Recommendations for Implementing the Right Cloud Crypto and Key Management Solution

Online Shopping Security in the Age of COVID-19

Published Articles and Press Releases

Videos