There seem to be so many vulnerabilities out in cyber space right now that everyone is hearing about at least a couple of them. As you dive in with concerned clients about the Kaseya attack or other big attacks making the headlines, you probably will want to come up with a way to explain vulnerabilities to your less technical clients in a way they can understand.
My go to analogy?
Buying a lock at Home Depot.
What if you went to Home Depot and purchased a brand new lock for your front door. You get it installed and feel instantaneously safer.
A couple of months later, you get a letter from the manufacturer saying that there is a problem with the lock.
The actual issue: If someone were to stick a metal pick into the lock, jiggle it to the left three times and then push in and out of the shaft 4 times, the lock unlocks.
This letter was shared with you, posted on the manufacturer’s website, and distributed across the hundreds of Home Depot stores carrying the specific model.
If a burglar interested in easy entry houses knew that you had this lock AND knew about the vulnerability associated with the lock, wouldn’t you think they’d at some point take advantage of it?
You better believe it!
Until the manufacturer came up with a fix to the lock (say, installing 4 additional screws in the door) OR you deciding to scrap the new lock for something else, you would be vulnerable to neighborhood thieves with a sure-fire way into your house.
In the IT world, this analogy may seem a little silly, but I’ve found it works perfectly with people that don’t care much about the nuts and bolts of their security. They really only care that things are working and that their locks aren’t broken!
Now in the real world, we have a variety of vulnerabilities that could lead to a network compromise. Probably the most common is software, but physical problems, personnel problems (social engineering), or outdated systems may all contribute to weaknesses that let bad guys in.
So… What are CVEs?
CVEs are a common way in which teams can track vulnerabilities impacting systems. CVE is short for common vulnerability and exposure. CVEs should matter to you because they will show a traceable way for a vulnerability to impact your network.
Just as the bulletin of how a vulnerability in a lock could lead to an open front door, CVEs around software bugs notify folks on how bad guys could misuse the vulnerability to break into your network.
The common identifier makes it easy to share information about a vulnerability across multiple databases, tools, and services.
Let me be clear. CVEs are not a vulnerability database. CVE is designed to allow vulnerability databases and other capabilities to be linked together, and to facilitate the comparison of security tools and services.
Are CVEs helping hackers?
Of course, hackers can use the information within a CVE to exploit a network. Experts that produce CVE notices see the benefits of informing the community of the vulnerability outweighing the risks of an exploit.
If you step back and think about it, even if there were no CVEs publicly available, it would take much more work for an organization to protect its network and fix all possible holes than for a hacker to find a vulnerability, exploit it and compromise the network.
What should MSPs do?
When I was running my MSP, I used to make sure my team understand what a CVE was. I’m talking about why have CVEs and what vulnerabilities are. This gave them a better framework to think about vulnerabilities or potential vulnerabilities in our or our client networks.
The more your team is engaged and understands common vulnerabilities, the more likely they will be to take action in response to a critical vulnerability.
Being able to read a CVE and find critical ones is important to prioritizing your network security.
One easy way to do this?
Many MSPs turn to a Cyber Stack Evaluation as a way to know if their teams are on the right track when it comes to adhering to good security practices.
