I'm sure you've heard the famous line from T.S. Eliot's poem, The Hollow Men:
"This is the way the world ends
Not with a bang but a whimper."
Well I'm here to tell you that sometimes major changes with profound effects also start with a whimper, or perhaps a whisper too easily ignored.
Great changes are coming to our industry. Not bad things, but big things. Things that will make it a little more difficult to operate. Things that will make your tools more expensive and your operations a bit more bureaucratic. What are these major changes?
Quite simply, we are quietly entering an era of data transparency and accountability that hasn't existed before. Which data? All the meta data and supporting system data that's used to monitor, update, access, backup, and secure your client's information.
This data includes everything client-related in your PSA and RMM tools. For example, the entire configuration of how you manage clients. Alert level settings. IP address information. Successful and unsuccessful checks. Logs of everything that happens inside your RMM tool.
The whisper came in one of the CISA documents I blogged about recently: "Risk Considerations for Managed Service Provider Customers." See https://www.cisa.gov/publication/risk-considerations-msp-customers.*
That document gives some very specific advice to your clients, including advice to require an MSP to provide . . .
- "Direct access to security logging information, network intrusion detection, and anomaly analysis data telemetry from all systems managed by the MSP that support the service being procured"
- "The ability for the customer organization to examine the systems that directly and indirectly support the contracted service on-demand by the customer organization with appropriate data handling considerations."
As I pointed out earlier, I don't know of any tools that currently exist in the SMB space that make this reporting and access possible. But if your RMM vendor isn't working to create this kind of reporting, you may find yourself looking for a new vendor.
Within about five years, I predict that MSPs will be reporting "data telemetry" to their clients on a regular basis. This will include a standard list of what you monitor, how frequently you monitor it, who has access to your dashboards, how one client's data is securely separated from other clients' data, etc.
All of this information has to exist somewhere inside your RMM or other tools. But you probably don't have access to it. That's why I call it meta data: It exists in support of the services you provide, but you don't have any way to back it up, print it out, or show it to clients (or government agencies) that ask for it. It's simply the bits and bytes that make the tools do what they do.
On a somewhat unrelated note . . .
I had a chat with a MSP owner last week who had a startling realization about her RMM, which I won't name. One of her employees accidentally applied a filter to a dashboard. So, when the owner logged in, she only saw her own company and two clients. Everyone else was GONE - or so it seemed.
She panicked. "How will I recreate every piece of monitoring, scripting, and reporting for every client?" She soon discovered that this was a filtering issue - but not before her brain went scurrying off to settle the question. She contacted the RMM vendor and was told:
"Sorry, you're out of luck."
All that information is somewhere in the cloud, controlled and monitored by the RMM vendor. But it's not backed up in a way that could actually be restored for one client or one MSP. In other words: You need to back up all that configuration information by hand.
She didn't give up. This can't be true. There has to be a way to access the settings for MY business, MY clients, and MY contracted data services. The response was only a tiny bit alarming: The only way to do that is to have an on-premise server. That way, you've got your SQL database. And however difficult it might be to get the data out, it will be on YOUR backup of YOUR database.
A-hem. Except . . . if I'm correct, ALL the recent "supply chain" ransomware attacks have involved on-premise servers and not cloud services!!! So how do I back up the client-related data in a cloud environment?
You simply can't.
We don't make that available to MSPs.
You just have to trust us.
THIS, my friends, is going to change. Whether they like it or not, RMM vendors will have to make these reports, this data, and these configurations available to you (and your clients) in the next few years. And, in a less cumbersome challenge, PSA vendors will as well.
Ultimately, we as an industry will be asked to address a very important question: Who owns the data involved in monitoring and managing a client's network? Is it the RMM vendor? The MSP? The client? The answer matters!
If the RMM vendor owns this data, then what do they owe the MSP or end user? What reports are reasonable? If there's a ransomware attack or other cybersecurity attack, what should the MSP or their client expect? Like it or not, you should be able to document this information.
If the MSP owns this data, what reports do they owe to the end users? Should this information flow on a regular basis or just when there's an incident? (BTW, I fully acknowledge that clients will ignore 97% of this information until there's a cybersecurity attack.)
But if the MSP owns this information, it should be downloaded, separated by client, and backed up. For how long? You need to add this to your general data retention policies. Some things we keep for three years; some for seven; some forever. Where does client monitoring telemetry fit in the big data retention picture?
If the end-user client owns the data, then the picture changes considerably. If the client owns the data, they should be able to take their "monitoring profile" to another MSP and get equal (or very similar) service based on the devices being monitored, the thresholds for alerts, the automated responses or scripts being run, and the reports being generated.
NONE of this is possible today. Even at the enterprise level, I don't think this kind of data portability exists. But once someone (e.g., CISA) lays the groundwork for expectations, I think you'll see these kinds of requirements finding their way into to requests-for-quotes.
Perhaps the closest analogy for most of us is HIPAA - Health Insurance Portability and Accountability Act. In this case, maybe it becomes CIPA or Client Information Portability and Accountability. If someone has a better term, I'm open to it.
What data, or meta data, should be made available to clients with regard to the monitoring and management services you provide? Aside from merely making useless information available, what USEFUL information should be made available? Ultimately, there should be some standardized reporting made available to law enforcement and insurance inspectors after a cybersecurity incident.
What can a client reasonably expect? Again: I fully acknowledge that most clients won't care. But more and more, their insurance company will care. What actually-useful information can you provide to clients who dutifully pay their bill every month and expect your to just take care of their network?
. . .
I almost started this post with an apology. I'm sorry I have to write this post. And I'm sorry you need to read it. But you need to read it.
The details will be worked out a bit at a time. But, in the big picture, I think this is the world you can look forward to. Luckily, this is an evolving world. And that means you can join in the conversation and help mold the future as it emerges.
PLEASE leave comments and questions. I'm happy to respond.
-- -- --
* I previously blogged about the document itself (https://blog.smallbizthoughts.com/2021/09/the-government-is-telling-your-clients.html) and some things you should be doing right now in response to this (https://blog.smallbizthoughts.com/2021/09/three-things-you-should-do-in-response.html).