MSP’s must do a security audit

It’s been in the news everywhere. Managed Service Providers are now a favorite target of hackers and their ransomware attacks. The bad guys know that MSPs hold a lot of sensitive information and keys to many kingdoms. They also know that the cobbler’s child has no shoes. So, they’ve decided to make bank on the reality that MSPs aren’t protecting their own data nor their access to client data very well. I’ve seen many MSPs looking to the developer of the software tools that they use to come up with a solution for them. Sure, those software packages need to get better but that isn’t where the solution should end. What should be happening instead is that MSPs should conduct an internal security audit, determine their weaknesses, then make sure that the solutions to those weaknesses happen. If you just jumped from Vendor X who needs to fix their software because that’s how data breach Y happened to someone else, then you’ve missed the point. If that breach didn’t happen to you this time, consider it just a shot across the bow. Everyone should now be woke and perform an internal security audit.

Performing your internal security audit

First, let’s note that I’m just an MSP owner and not an auditor. But any good IT professional knows a few things about where they store data and how they access their clients’ infrastructure. In addition, any good IT provider also knows that you can’t rely on policy alone (otherwise we wouldn’t have people still using simple passwords or the same password for different logins) to secure information and remote access. We have to have hard blocks and good practices together and ways to verify that it is working.

Pull together your team

My MSP has eight people. It’s a pretty typical size for a mature firm. We called an all-staff meeting. I laid out the information from the news about what had happened to those high-profile MSPs and what the response from the software vendors had been. Then we reviewed our practice.

I could have done this all myself, but it was important that everyone was on board and that we used everyone’s brain to recall where absolutely everything with any sensitivity was stored. Of course, we knew where it was supposed to be stored but we needed to expose the anomalies too. Once we got the ball rolling everyone then felt comfortable verbalizing where we’re doing things right and where we needed to be better.

What do we look for?

The kinds of data that MSPs are housing that if in the wrong hands could be very bad include at a minimum the following categories of items.

• Remote access to a client computer, server, firewall, switch, phone or other infrastructure.
• Storage of documentation, credentials, and billing information.

What will the bad guys do with this information? Well, obviously deploy ransomware but they will also gather data to perform future spear-phishing attacks and deploy malware that could sit there for a very long time (six months is now the average) before making itself known. Can you imagine the damage that would do to your business reputation? Are we or the tools we depend upon using insecure methods for authentication or access? These include things like the following:

• RDP
• IMAP, SMTP, POP
• PPTP VPN
• SMB

There are several ways that you can expose this information. Your knowledge is the first one. Most people know if they are using RDP or not. But the others might not be obvious depending upon the tool. The first task then is to ask the vendor from whom you purchased the tool. What is the protocol in use? What authentication method are they using? Other ways to discover this information include sniffing tools like Wireshark or authentication logging. If these things are being used, turn off that option, or if that isn’t possible, stop using that tool and get a new one. There are plenty of good tools that don’t violate today’s security standards. You may have to leave an old standby, but so be it.

Are you using MFA to the fullest extent possible?

Multifactor authentication should be turned on for everything. Everything means everything – it includes the documentation store, local accounts, password storage tools, remote access tools, and more. Any access to anything should require MFA. It’s a pain, no one loves MFA. What do you do about shared accounts? Many MFA tools support connecting multiple devices.

What about those passwords?

It has been standard practice to tell users to change their password often, use complexity, and make them unique to all others. MSPs have been caught not following their own advice in these continued hacks. Ask yourself these questions:

• Are all local admin account passwords unique?
• Are all device passwords unique and not the default password?

Local admin accounts being enabled and all having the same password across the network were the No. 1 cause of lateral access in ransomware events. Those must have unique passwords. Microsoft makes a tool called LAPS that should be part of your standard toolkit. LAPS will make sure that unique passwords are in place. Optionally there are third-party tools that will change the password with every use.

Does one piece of information accidentally give access to other pieces?

This can harken back to the above-mentioned use of the same password, but it can also be a failure of keeping everything in one place. When you enter your credentials do you get access to remote access, passwords, and documentation all at once for a single client? When you enter your credentials do you get access to those things for multiple clients? One is obviously worse than the other, but both are bad and should throw up red flags in your audit.

Make a plan

Now that you’ve identified where the problems are, they need to be corrected. Those corrections are going to happen in several different ways.

• New procedures. Perhaps in the form of subdivided rights. Or perhaps moving different types of data behind different types of storage instead of together.
• New policies. Just don’t rely on the policy that says, “Just don’t do this.” If you implement a new policy, make sure that you are also able to verify that it is being followed.
• New tools. Say goodbye to old tools that don’t meet today’s security needs. It happens to your OS, it happens to everything.

Create a remediation team

Set a task for each of your team members to make the changes necessary to bring more security into your practice and secure yourself and your clients against becoming the next victim of contracting with an MSP. Hold regular report-in meetings so that everyone can see everyone else’s progress. I found that peer-pressure helps keep that sense of urgency going.

MSPs must do better as an industry

In the end, we want businesses to feel secure that when they use an MSP, they are doing the right thing for their business and not exposing it to another threat. It’s one thing to know that we as MSPs want to operate efficiently with as little productivity friction as possible and another thing to put our clients at risk. This isn’t something that we can balance. It is something that simply can’t happen. We must do better as an industry.

Make your IT business better than the competition. Help for IT Pros, TechYourBooks, Super Secret News, Women in IT Scholarship program, Ransomware Prevention Kit, 365 Security kit and more. https://www.thirdtier.net