Managing Service Providers for Security and Compliance

I was recently on the Cloud Bytes podcast talking about how service provider management is integral to having a secure environment. Service provider can mean a lot of things and the following is by no means a comprehensive list:

• Internet Service Provider
• Managed Service Provider (Partner or VAR)
• DNS Service Provider
• Cloud Service Provider
• Contractors

Even when we've locked down everything we can think of in our own datacenters and campuses, we just can't have complete control over what others do with our data and workflows. However, we can always reduce potential harm and that's what we talk about in this episode of the podcast, within a whole season of episodes dedicated to security.

Who's responsibility is it?

We often find ourselves working in a culture of finger pointing and passing the buck. Even when fingers are pointed in the right direction, though, it doesn't mean we've come to a solution. The solution is what really matters, especially if we're talking about something which may be causing downtime due to a DDOS attack, for example, or assets not being up-to-date in their security posture. So, maybe the question "Who's responsibility is it?" is actually the wrong question. The correct question is:

"When this happens in the future, and it will, how are we going to work together to fix it?"

Technically, the responsibility is on all of us to make sure we have a plan like this in place, but it might behoove you to make sure this plan exists over relying on your service provider to do it.

To get started on creating this plan:

• Always read the fine print. Make sure things like HIPAA and SOX requirements are being met if that's a requirement for you, or may become a requirement in the future.
• Get to know incident response teams before you have an incident. Understand how they work, what their SLAs are, and what kind of support you have set up with them.
• Create a runbook of what needs to happen in common cases like an outage or breach and make sure you have a mutually agreed upon action plan, especially with smaller providers who might be more like part of the team.

Creating a MAP

Documentation is not everyone's favorite work task, but it's so important to create a MAP, or Mutual Action Plan, which includes vital information like Roles and Responsibilities for both internal and external roles. For example, your internal teams may be responsible for data, but the CSP team may be responsible for services. Now you also have to consider what might be considered a gray area, for example, if you're using AWS Route 53 and DNS goes down - was the issue with configuration or with the service itself?

Once we've established who's responsible for what, it's important to validate and document that we currently have, and will always have, visibility to anything we're responsible for. Often we don't get a lot of troubleshooting data from a CSP, so ensuring that we can troubleshoot what we're responsible for is key.

Another important piece to document is how communication and coordination will happen. What is the responsibility and the SLA of the provider to let you know if something has gone wrong? Having this documented will give you peace of mind and perhaps even legal reconnaissance should something go wrong and you're not notified in a timely or appropriate manner.

Once you've discovered SLA, then you also need to ensure that your SLAs match the provider's SLAs. If they don't match, then you need to come together on that and document it.

The last thing is to make sure your documentation of all of this will be available to you, even if service is not. It's not going to help if your documentation and run books are stored on AWS, and then the instance of AWS goes down and you don't have access.

On Working with Smaller Service Providers and Contractors...

Things happen, phones get left in rideshare vehicles, laptops get stolen. The human element is something you must always account for when someone has your data and/or passwords to access assets on your network.

• Consider asking your service provider how they store and manage passwords.
• Are they going to be traveling with your hardware assets like laptops? Figure out the risk factor vs productivity factor and see where you land.
• Are they going to be adding software to their hardware assets? Do they have and will they need admin rights over the hardware assets they're using?
• How do they secure their own environment at home or at the office depending on where they work?
• Ask for a Compliance Attestation, and take it a step further by asking for a 3rd party to validate their compliance and/or security.

Dependence on a Single Provider

I've talked about it at length on blogs such as this one on xDNS but it remains true. If you're dependent on a single provider, you should expect downtime. The only way to avoid downtime is to implement multicloud and multi-service architectures. This isn't easy, because it just adds to the growing complexity of your environment. It is necesssary, though, if uptime is important to your business and specifically your revenue.

Get Started Now

Start using built-in documentation and put the control back in the right hands, by trying out our Micetro Free Trial.