What makes MDRs differ?

In a world post Solarwinds supply-side hack, a world where Kaseya has had several vulnerabilities, what can customers really do to feel comfortable about their security if they are using RMM solutions and an MDR to help qualify and verify security risks before they occur?

Well, there's a few components to realize.  The first is that not all MDRs are created equal.  This is obviously something MDRs will admit - they will all individually tell you their service is better than their competitors... but the reality is that some are made better than others.  An MDR solution that allows active response - being able to shutdown or lockdown a system that is showing indicators of compromise is better than a log aggregation tool that gives you an email or text when a breach *might* happen.

By the time your employee gets a call at 2:39 AM on a Sunday Morning, the breach may have already hit several computers and you're dealing with clean-up... not containment.  And containment of early indicators of the breach is going to be a success.  That's a best case scenario - but a completely possible one as well.
 And an MDR without that capability is depriving a key victory from your security team and trading it for knowledge of when to begin starting backups.  They aren't comparable!

The second component to realize for most companies, is that an MDR doesn't excuse poor security hygiene.  What does this mean? Well... for example:

  • Do your users have local admin accounts?
    • This is still a problem in 2021! Sometimes Help Desks will set systems to have a local admin account to prevent repeat calls into support when they need an application installed, etc.  This leaves huge vulnerabilities in your environment because Windows password security has been compromised multiple times - enough to show you that privilege escalation WILL happen if a system that shouldn't have admin credentials is left with it.
    • Are you using an admin account as a security administrator? You shouldn't be. You should use an account with ONLY the access and privileges you need, and simply login as admin when necessary.
  • Are you using Multi-factor authentication?
    • This is key - because as we've seen with Windows passwords, a second layer of authorization is going to save you from many many attempts on your key servers and systems.  Adding MFA can stop a breach from happening, and prevent a lot of drive-by malware attempts from succeeding.
    • If MFA is available... use it.  Any application that offers MFA, use it.  Devices have an MFA? Use it. There isn't a question of whether you should or shouldn't use an MFA - because you should - but you should also encourage regular users to use an MFA as well.
  • Are you cloning accounts or active directory groups without checking whether users need those permissions?
    • Sometimes along the line an AD user group will be adjusted to have specific permissions they needed for a set amount of time... and then that group will be cloned for another user group that you are bringing in for a project or a specific purpose.  This can leave users with privileges they don't need, and additionally, security vulnerabilities you don't want.
    • This a fairly straightforward practice where if you are going to clone an AD User group - simply verify the permissions are what the users in that group need... taking a less is more methodology when it comes to permissions and administrative access.
  • Do you have a process for what to do in a breach?
    • If you have an MDR service, or are using an MSP - have they provided you a document that lists who should be called, when they should be called, and what the next immediate action is if a breach occurs?
    • Does your organization have a process to follow if you don't have an MSP or MDR to assist? Do you know who needs to be called? Do you know what back-ups to set up? Do you know what servers to take offline first?  These are all questions you will want quick answers for in the case of a breach, and spending a couple hours going through and creating a simple plan is a good call.
  • What are the compliance requirements for your industry if you have a breach?
    • This is a question ever Manager or Director level person should expect from the C-suite.  There is an increased interest in understanding the liability issues that can arise from data being viewed or potentially viewed in case of a breach - as well as what kind of process may be required for an insurance claim to be filed in the case of cybersecurity insurance or fraud insurance.
    • This information is not something you want to find out after a breach occurs. You want to know the answers to these questions before you get pulled into a very uncomfortable meeting with your board of directors.

The biggest take away from this second consideration is... does your MDR have the ability to react or take action versus just respond with an email or text to a person for them to do something.  And if the answer is no they don't - you should consider reaching out to London Security to find out what would happen in an actual breach / ransomware event.

London Security offers a Ransomware Risk Assessment which is the industry’s only ransomware risk assessment that uses deconstructed scripts from actual ransomware variants.  I know you probably have done all sorts of audits and vulnerability scans.  But... I’ll bet you never ran an actual ransomware risk assessment against your environment to see how it would respond, what alerts would be generated, and if what would impact your business directly.
Interested?  Take the next minute or two to check your schedule and then contact us with a time where  you have about 10 minutes for me to explain how this works.  And by the way…none, not a single one of our customers have been impacted with Solarwinds, Kaseya, or any other of these RMM solution issues while using our MDR Service, so we recommend you consider giving us an email today!