top of page
  • Michael Feinberg

Dark Reading and RMM

Despite enormous efforts and sums of money spent on cybersecurity, threat detection, and education, the breaches and hacks just keep coming. The recent high-profile compromise in supply chain illuminates (if only briefly) a problem we’ve known about for a long time… The software tools!

Remote Monitoring and Management (RMM) are software-based tools that are a necessary and critical aspect of the Managed Service Provider (MSP) infrastructure. To effectively service their customers, MSP’s IT employees must be able to remotely access workstations with an administrative level of access.

MSP’s range from small, localized companies all the way up to large conglomerates; however, in almost every case an MSP’s own line of business is not that of “software publisher”. This means (specifically) that MSP’s will purchase or lease software tools (such as RMM) from other third-party software companies. To the sophisticated hacker, this is the obvious point of massive “trickle-down” opportunity, and hence the recently exposed “supply chain” problem.

Companies like Kaseya that cater to MSP’s make it simple for MSP’s to co-brand their RMM tools and easily provide support services (and a level of sophistication) to their own customers. Lesser understood by those outside of the industry is the billing model that MSP’s now frequently utilize.

Kaseya’s RMM tool incorporates time-tracking at the end-point level as well as remote monitoring. With the high cost of IT labor and razor-thin margins, it becomes virtually infeasible for smaller MSP’s to try and bill their customers hourly for outsourced IT staff. Instead, they more typically bill their customers by the total number of endpoints serviced. With few other tools capable of drawing together the combined concepts of time-tracking (billing), remote desktop access, and remote monitoring; MSP’s have relatively few choices in the software tools market. For this reason, we’re likely to see more (not less) concentrated attacks against the supply chain. It’s an obvious target that MSP’s can’t easily pull back from because the tools are at the forefront of their own billing mechanisms and even core to their business model.

Solution #1:

MSP’s can prevent the single point of security failure by separating the tools they use. For example, utilizing RealVNC for remote access, a combination of BelManage and SonicWall for Remote Monitoring with End-Point protection, and QuickBooks Time for billing; the MSP could effectively decouple itself from the most obvious points of supply-chain compromise. At a similar overall (combined) price-point for software licenses, this strategy only requires slightly more initial setup work on the part of the MSP. It does not represent a general incremental change in their overall software licensing cost structure.

Solution #2:

Assuming we extrapolate further on Solution #1 (above), the MSP has within their power the ability to create very strong (hard) and unique passwords (with MFA) for every endpoint they manage as a custodian. Responsible use of password managers (like as well as clear delineation of IT Agent access rights (such as in can stop the supply-chain attack cold. MSP’s have an opportunity to self-improve by being more vigilant about their ways and means for executing RMM.

Solution #3:

Even the best laid plans will fail. Planning for such failure ahead of time should be the fiduciary responsibility of every MSP as the steward of their customers’ IT and cybersecurity. Addressing one of the deadliest security issues for companies, (the ransomware issue), can be more easily solved with a robust, well-coordinated, and mature software backup plan.

For example, let’s say that Company-A (“CA”) deploys Veeam backup agents to all their employees’ end-point workstations. Further, they incorporate server-side Veeam backup for all virtual machines, servers, and cloud assets. They add Veeam1 Reporting for customer human-eyes on reporting on all backups or backup failures. (Failed backups don’t help anyone!)

CA’s MSP is thus responsible for maintaining a daily, weekly, bi-weekly incremental backup series as well as monthly full-back (clone) images of all systems. CA’s MSP keeps the company’s long-term storage and archival costs down by using their own (internally managed) hard-encryption of the Veeam backups and maintaining them in safe cold-storage. CA’s MSP has a well-defined Disaster Recover / Business Continuity (DRBC) plan to resurrect data from storage in a controlled and pre-defined amount of time. CA’s MSP tests (and re-tests) the DRBC recovery semi-annually.

Ultimately, a member of the MSP’s own IT support staff will inadvertently become the attack vector that passes zero-day malware onto one of their customer’s endpoints. What happens next when the endpoint has an outdated Anti-Virus profile on it and then proliferates a crypto-locker style ransomware throughout the customer organization?

At that point, the very best recourse the customer (and the MSP) has, rather than pay ransom, is to execute their well-defined DRBC policy and recover customer’s systems from a clean restore point. The more comprehensive the backup coverage, the more effective the DRBC. The backups must be checked (manually) daily, and the MSP must utilize their own encryption to control the backups. It is the MSP’s duty to provide this service to their customers.

What questions should you ask your MSP before starting service?

· Does your RMM isolate access to each endpoint with a unique hard password with MFA?

· Do you consolidate all your tools into one place, or do you maintain them separately?

· Will you apply backup agents to all workstations, servers, and cloud assets?

· What is your backup, archival, and DRBC strategy in case of malware?

· Will you certify backups daily by activating backup reports that are visible to you and the customer?

· Is email security part of your core service offering? Does it include DMARC, DKIM, SPF, and BIMI protections?

· Do you utilize your own encryption tools for securely controlling your DRBC policy?


bottom of page