No one wants to hire a managed service provider only to discuss a “shared responsibility” model. Isn’t the point to minimize responsibility, not debate it and lay it all out in a document?
We hear you. We also hate to tell you that no matter how hard you try, you’re always going to have some role to play in protecting your infrastructure. Even in the public cloud, resilience is your responsibility.
The only choice you have is whether you’re prepared with a plan when you need it.
Denial won’t get rid of security and compliance risk
The natural impulse is to lift and shift. Lift and shift your business to an MSP, to the cloud, and lift and shift the responsibilities off of your team. In the information security realm, there’s the concept of transferring risk. That doesn’t mean absolving yourself of risk. Part of that risk will always remain with the organization that owns the data and the applications, even if it’s just monitoring and managing how the risk is handled.
Believing in a totally carefree cloud requires strategic denial. Both Microsoft Azure and AWS provide clear documentation about how responsibility is shared with the people who use the public cloud. Most people, however, won’t go looking for those answers. And if you don’t see it, you can continue believing that it doesn’t exist.
Unfortunately, just like with taxes and speed limits, pleading ignorance won’t save you.
Making a map of your data center and cloud services
That extends to ignorance about what, exactly, is being protected. At Deft, we untangle unknown infrastructure and shadow IT all day. It is the hardest thing to get your arms around at the start of a project, and the hardest thing to protect against, because you can’t manage or protect what you can’t see. A cloud access security broker, or CASB, solution, is a great example. It’s able to enforce security protocols for anything that happens on the network. If anyone does anything off network however, and they will, the solution fails.
Still, most organizations will have some ledger of assets, whether to satisfy compliance requirements or inform a disaster recovery plan. Even if you have to go to finance and pull receipts, you can come up with some map of what’s in use on-prem, in the data center and via SaaS and cloud platforms. Once you have this starting point, you can begin to decide who is responsible for what.
Navigating tough division of responsibility conversations now avoids finger pointing later
No one wants to make it awkward. When you like the people you’re working with — and you really should — it’s hard to ask what happens in a worst case scenario. A business can talk all day about the financial impact of an outage, or its impact on customer satisfaction. When it comes time to talk about what it would really look like, who’s responsible for what and who ultimately would hold the blame, those conversations aren’t as easy.
A good MSP is a partner who will force these conversations. At Deft, we want to explicitly tell you what we’re going to be able to do for you, and where we’re going to need you to pitch in. Those are not the details to figure out when the systems are down and the pressure is on.
You should expect your partner to take on some of the responsibilities for owning the security of your systems. Just not all of the responsibilities. We find it really helpful to talk through specific examples. What happens if someone connects to the coffee shop WiFi or uses Dropbox when they shouldn’t? Walking through theoreticals is a great way to get to the practical applications of a shared responsibility model, without any finger pointing.
Negotiating a shared responsibility model
First, accept that it’s never going to be as clean as you want it to be. You can’t plan for every eventuality. As long as both sides are communicating and acting in good faith though, it will work.
A great place to start is with the CIS Critical Security Controls. Look at the list and start to evaluate: Where are there gaps? What’s already covered? If you’re a regulated organization, maybe you’ve been doing some of these tasks forever.
Once you know what needs doing, you can start to divvy up the responsibilities, mapping some to your service provider and some onto your own organization. The great thing about the CIS controls is that you can tackle them by implementation group. The first group really articulates the baseline of what every organization should be doing. Get those under control — some of which are plenty difficult — then work your way up to meet the level of security your organization requires.
Even “simple” tasks make for complicated responsibility models
So much of building a resilient hybrid infrastructure boils down to two questions:
- Are we backing everything up?
- Are we patching in a timely manner?
That makes it seem easy, but each question breaks down into many, many more responsibilities. You have to make sure you have a full accounting of everything that needs to be backed up, then test those backups. You have to know what’s unpatched, how old your oldest patch system is, whether anything would be considered out of the service, if there’s anything running that’s no longer being patched. Those are all critical questions, and someone needs to own each of the answers.
Once you have a shared responsibility plan, communicate it
As important as all the steps above are, none of them hold a candle to communication. That’s the key of anyone’s business continuity or disaster recovery plan — having the scripts ready to go and communications ready to send.
Balancing that awareness is tricky. Too much communication, and it becomes background chatter. Too little, and people don’t have the tools they need to properly respond. Get it right though, and your organization will literally be ready for anything.
A lot of employees — even management — will sort of shrug it off and say it’s never going to happen. And quite frankly they may be right. Disasters don’t occur to a lot of businesses. When they do though, having the conversations outlined and the plans in place will ultimately determine how quickly you’re able to bounce back.
