We make it a point of teaching our users security awareness at least once a year. But what we aren’t thinking about is how many times a day we may be inadvertently teaching our users to be phished. But before I talk more about how (and why) we might be doing our users this disservice, let me give you a little background on how we have arrived at this particular juncture.
Many of us in IT started as just the computer person. In the beginning, we just needed to help people logon with credentials, fix hardware drivers for them and make their pie charts green. Soon, we moved from being IT generalists into the bigger and much more complex role of security experts. The next thing we knew, we were challenged to protect not only the perimeter but also now, each unique endpoint.
Then, endpoints started getting pretty jinky. With BYOD and cloud, users were using a variety of machines to connect from anywhere, to anything, on any network. With Zero trust from the outside to the inside of our networks we have found that we can no longer trust the perimeter to keep devices safe. In other words, we are now challenged to determine how to trust each device that we are requesting to interact with. Luckily, we still have the Root of Trust or the Web of Trust models to help us identify these different actors on our networks.
We use x.509 certificates with the SSL/TLS protocols and SSH keys to establish Identity of these many interconnecting machines. To accommodate this shift, many like myself have had to evolve from being just a computer guy to being experts in protecting machine identities. In fact, given the explosive growth of machines that our organizations rely on, we are all speeding down the byways in a journey from generic computer stuff to a very specific, high value targeted machine identity protection.
Machines do a great job with trust. It is a binary answer. I trust you and will do business with you or I don’t trust you and we will kill communication. With humans, it’s not so easy. When accessing a variety of web pages in a variety of browsers over a variety of WIFIs, there are just too many variables for humans to effectively establish trust. And we may be inadvertently exacerbating their inability to decide what to trust. Every time we create a situation where they are allowed to click through a security warning, we are essentially training these users how to be phished. How are you training users to be phished?
Users have a job to do and they need to connect to something specific to get it done.
Every time they attempt to connect to something where the trust on a certificate is broken, we prompt them with an error. We issue certificate warnings for security events, such as:
Domain name mismatch
Certificate chaining issues
Key strength errors
Each time a person interacts with a certificate error we are reinforcing their likelihood of being phished.
Even though they are not machine identity experts, they still have a job to do and they are going to click past that error and accept the risks. Here are some of the riskier places we commonly see certificate warnings:
Internal networked resources
Users generally skip over these errors because the warnings may seem harmless at best (or indecipherable at worst). And they are rewarded by getting to their resources successfully.
Congratulations, your users now associate certificate warnings as a nuisance and are more likely to click past a dangerous one where they will enter Domain credentials and nicely hand them to a bad guy.
This is our fault for training users to just click past these warnings.
Some browsers such as Chrome are fixing this by not allowing users to choose to accept the warnings. They simply reject the connection. But there are a lot of browsers and applications that do not. We should handle each certificate error as a service failure and, even worse, as a training to teach our users to be phished. Better yet, we should avoid these errors in the first place.