Every day it seems like there’s a new Zero Day vulnerability about our websites. SSL is being deprecated, PHP is out of date, the CMS we use has a critical vulnerability, security isn’t all that safe, and OMG we’re all going to get our identities stolen and our lives hacked.
Making matters worse are those myriad security tools we use to keep ourselves from getting hacked or attacked, and they alert us to horrible things. I say worse because they terrify people without actually explaining and educating them, so the uninformed users come running to complain the sky is falling. And when those people are told an answer by other experts, they don’t know who to believe.
Can you blame them?
Responsible Disclosure
It’s four years now, and Nacin’s post about how security is nuanced is still required reading.
The problem we face is that telling the world about a security issue is complicated. We definitely need to tell people who are responsible for fixing it, and in a perfect world we should trust that they’ll push out that fix in a reasonable time frame. We also should be able to trust they’ll tell the appropriate people.
But who, exactly, is the appropriate person to tell about a Drupal patch? Not the hack, the patch. In a different light, who are the right people to tell that a new security fix for an operating system has been released?
There are millions of users. How do you get to all of them quickly, with the right amount of information so they can understand how important this patch is to them, and how quickly they should apply it?
Enter Security Companies
Many companies make their milk and meat off being the people who monitor and announce security releases. There’s nothing wrong with this. In fact, I laud them for being a much needed service. With so much data flowing, it’s important to have a service that can help users winnow down what’s critical to them and their setups.
But… That’s not what’s happening.
Security companies face the same problem we do. There’s just too much data, and it’s being updated all the damn time, and there’s no way to keep up with all of it. Which means that they do what I tend to do when I’m trying to explain things to a wide variety of people. They simplify as much as possible.
The problem with simplification is that you have to skip over things and leave out the nuances that help people understand what’s actually going on. They have no idea what they actually need to worry about. And we’re back to zero.
To Know When To Worry …
You have to actually understand context to know what to worry about.
There’s literally no other way around it. There’s no shortcut, there’s no cheat sheet, there’s just knowing what your site is doing.
Let’s taken OpenSSL as an example. Back in 2014, a serious issue called HeartBleed was discovered. The bug was phenomenal in that it allowed people to steal and read secure data. If you ran a website, this was a massive issue. For your webhost.
Was it a huge issue to you? Well. Maybe.
A lot of people sounded the alarm and declared this a crisis, and we should all grab our web hosts and asks what they were doing and when would we be fixed. And the rest of us said “Hang on. Webhosts are aware. See if they have an announcement, which most will, and if they say they’re working on it, trust them.”
Sounds like I’m passing the buck, but the reality is that unless I’m using my site for privileged data (like a private blog, or a store), then the odds are for my individual site … I don’t need to panic. Especially if I use unique passwords and take regular backups.
This doesn’t mean Heartbleed wasn’t a huge problem, and that I didn’t want to see my host putting this as their number one priority, but it means that I’m aware of the risk (private data being stolen) and the likelihood of it happening (moderate to high) and the level of risk. That last one is the most important.
What’s the worst that could happen, today, on this site if someone stole private data? Well. They’d see my password maybe, and some draft posts, and have access to my API keys for a couple services. Nothing I can’t fix relatively quickly. They can’t log in to those API services and they can’t destroy my life.
If I was still running a store (like I was at the time of the initial vulnerability), I paid close attention to the fixes being released and the moment one was out for my system, applied it. But there was no need to panic or rush about. I understood what was going on.
If You Don’t Know …
If, however, you have no idea how it all works and what it means, then I recommend the following checklist:
- Do I have good passwords?
- Do I have good backups?
- Does my web host have a reliable track record for fixing this stuff?
- Do I run any private/privileged data on my site that could be dangerous to release to the public?
If that last item is 4, then I better be paying my host (or an expert) a lot to protect me ASAP. If you’re still on budget web hosting, it’s time to move up to something managed, or hire someone to manage for you.
Otherwise, if the first three are all ‘yes’ then I’m not going to panic. I’m going to trust in the experts to do their job.
