Because most advanced persistent threats (APTs) succeed when someone makes an innocent error—clicks that link, runs that Java application—you’re probably looking for ways to train employees to see through common ruses. But if your organisation is like most others, it has thousands of assets that are working just as hard training employees to let the hackers in.
What are these assets that can work against you? Self-signed certificates.
Many organizations face a common challenge and frequently ask the question – why should we treat self-signed certificates in the same manner as we do other types?
Do organizations address any other security controls the way they do self-signed certificates – No visibility and No controls?
Certificates are used to secure and authenticate communications, yet organizations are doing nothing too keep it that way. Over 50% of organizations are not even aware of the number of keys and certificates used within their own environments. For any opportunistic cybercriminal, this is the perfect attack vector.
What self-signed certificates do in your environment
CA-signed certificates call on a trusted third-party to testify that, for example, a web server really belongs to your bank and not a hacker phishing for your account. A self-signed certificate, on the other hand, presents itself without any outside stamp of approval, relying on users to click past a warning to accept it.
Organizations deploy these certificates extensively on embedded web servers in printers and in network devices or perhaps even on internal-facing applications. Just like CA-signed certificates, self-signed certificates serve the important purpose of authenticating and securing communications—with the seeming added bonus of costing nothing and being easy to generate or even coming pre-installed.
Limited visibility
A Venafi customer performed a discovery and uncovered 87,000 records.
Of these records 63,664 self-signed certificates were discovered.
- {“key”:”Hewlett-Packard Company”,”value”:47894},
- {“key”:”International Business Machines Corp”,”value”:10360},
- {“key”:” VMware Inc.,”,”value”:4360},
- {“key”:” Dell Inc.”,”value”::1050},
Upon running a query Venafi uncovered ‘nine’ instances of a certificate introduced on October 3rd 2003, due to expire on October 2nd 2013. The organization was unaware of the certificates location, or how it was being used.
A wolf in sheep’s clothing
Self-signed certificates provide the perfect cover for advanced threats. In fact, the Mandiant APT1 report shows attackers used self-signed certificates, such as certificates purporting to be from “IBM” or for use as “WEBMAIL,” “EMAIL,” “”SERVER,” or “”ALPHA,” for control and control (C&C) cover
Consider a typical day for employees, whether normal users or IT administrators. Administrators might need to access an administrative console, so they click past a familiar security warning from the embedded self-signed certificate. Or users need to download and run a Java applet to offload processing from an older embedded web server. Again, they must click through a certificate warning.
The self-signed certificates become the boy who cried wolf, raising so many warnings during normal operations that users notice nothing suspicious when a hacker redirects them to a fake printer or network device. Similarly, users may click through Java security warnings and download and run a malicious Java applet on their machine. Many modern web threats silently hijack the browser, so the certificate warning might give users their only chance to save their machine from compromise. Instead, given nothing but a warning that looks so much like the innocent ones so long ignored, users let the hacker in.
How you can protect yourself
First, you need to realize that your organization likely has many self-signed certificates even if inventories indicate otherwise. A Venafi customer recently discovered that 63,664 of its 87,000 certificates were self-signed, and the company had no idea where those certificates were deployed.
Next, you must determine how you will counteract the bad habits that self-signed certificates are instilling in users. You might set up an internal CA and replace self-signed certificates with certificates signed by it. You might keep the self-signed certificates, but monitor their use more closely, training employees to recognize the certificates that truly belong to their appliances and applications.
In any case, ongoing visibility into and control over your certificate deployment, combined with enforcement of best practices, will provide your primary line of defense—helping employees recognize a wolf when they see one.
