Shared Security Model – Where Does Your Service Provider Draw the Line?

  1. shared security model service provider

FISMA… GLBA… SOX… HIPAA… PCI… If this looks like alphabet soup to you, you’re not alone. Many of our customers don’t know the full scope of the requirements that the government or other regulatory bodies hold them responsible for. It’s easy to get lost with the vast amounts of information and jargon in any compliance framework.

When you take the step to move your compliance based operation to the Cloud there is one major point to consider, the shared security model. If you are working with a service provider and they say that they can provide a HIPAA or a PCI solution (or whatever alphabet soup regulation your business is under), proceed VERY cautiously. In most cases you will be engaging in a relationship where the service provider may, and likely will, provide only some of the controls to assure the compliance you require.

Simply stated, the shared security model means that different entities will be responsible for providing the security controls to meet all of the requirements of a regulation. This very often includes responsibilities assigned to the customer (you!). This model is not new. From the very early days of Cloud hosting, most providers drew the line in terms of security controls to exclude the customer’s application code. This was because, in general, the customer would have a MUCH better view of the development methodologies and be in a better position to assure proper security focused development was occurring. Additionally, many regulations require a lot of internal policies and procedures, and documentation thereof. Again, most customers would have greater visibility and control over that type of activity.

Times have changed a bit. There are now certainly organizations that will handle all aspects of your compliance requirements but that service comes with a hefty price tag. What you want to make sure happens, is that all aspects of the compliance framework, in terms of responsibility, are clearly defined by the service provider. What you don’t want to happen is to find out, possibly after an infraction, that a control that you thought your service provided covered, was in fact, in your realm of responsibility.

This is not an exhaustive list, and you will want to reference your specific regulatory framework to create a comprehensive list of controls, but below are some items you may want to consider from a responsibility standpoint:

  • Physical Control of Facilities
  • Physical Access Controls of Staff Based on Job Function
  • Encryption of Sensitive Data
  • Network Security (such as)
    • Firewall Configuration and Management
    • Log Management
    • Intrusion Detection Systems
    • Web Application Firewalls
  • File Integrity Monitoring
  • Customer Code Security Review
  • Governance, risk management, and compliance tracking
  • Network Communication Encryption

-Roland Scarinci, Senior Director of Solution Architecture at HOSTING

Make sure you don’t make a mess of your alphabet soup! See how HOSTING can help.

Leave a Reply

Your email address will not be published. Required fields are marked *