This post will discuss the division of responsibility between a cloud provider and you as a tenant, and how to define aspects of that relationship in your service contract. Renting a platform from a service provider does not mean you can afford to cede all security responsibility. Cloud services free you from many traditional IT jobs, but you must still address security. The cloud provider assumes some security responsibilities, but many still fall into your lap, while others are shared. The administration and security guides don’t spell out all the details of how security works behind the scenes, or what the provider really provides. Grey areas should be defined and clarified in your contract up fron. During an incident response is a terrible time to discover what SAP actually offers.

SAP’s brochures on cloud security imply you will tackle security in a simple and transparent way. That’s not quite accurate. SAP has done a good job providing basic security controls, and they have obtained certifications for common regulatory and compliance requirements on their infrastructure. But you are renting a platform, which leaves a lot up to you. SAP does not provide a good roadmap of what you need to tackle, or a list of topics to understand before you deploy into an SAP HCP cloud.

Our first goal for this section is to help you identify which areas of cloud security you are responsible for. Just as important is identifying and clarifying shared responsibilities. To highlight important security considerations which generally are not discussed in service contracts, we will guide you through assessing exactly what a cloud provider’s responsibilities are, and what they do not provide. Only then does it become clear where you need to deploy resources.

Divisions of Responsibility

What is PaaS? Readers who have worked with SAP Hana already know what it is and how it works. Those new to cloud may understand the Platform as a Service (PaaS) concept, but not yet be fully aware what it means structurally. To highlight what a PaaS service provides, let’s borrow Christopher Hoff’s cloud taxonomy for PaaS; this illustrates what SAP provides.

This diagram includes the components of IaaS and PaaS systems. Obviously the facilities (such as power, HVAC, and physical space) and hardware (storage, network, and computing power) portions of the infrastructure are provided, as are the virtualization and cluster management technologies to make it all work together. More interesting, though: SAP Hana, its associated business objects, personalization, integration, and data management capabilities are all provided – as well as APIs for custom application development. This enables you to focus on delivering custom application features, tailored UIs, workflows, and data analytics, while SAP takes care of managing everything else.

The Good, the Bad, and the Uncertain

The good news is that this frees you up from lengthy hardware provisioning cycles, network setup, standing up DNS servers, cluster management, database installations, and the myriad things it takes to stand up a data center. And all the SAP software, middleware components, and integration are built in – available on demand. You can stand up an entire SAP cluster through their management console in hours instead of weeks. Scaling up – and down – is far easier, and you are only charged for what you use.

The bad news is that you have no control over underlying network security; and you do not have access to network events to seed your on-premise DLP, threat analysis, SIEM, and IDS systems. Many traditional security tools therefore no longer function, and event collection capabilities are reduced. The net result is that you become more reliant than ever on the application platform’s built-in security, but you do not fully control it. SAP provides fairly powerful management capabilities from a single console, so administrative account takeovers or malicious employees can cause considerable damage.

There are many security details the vendor may share with you, but wherever they don’t publish specifics, you need to ask. Specifically, things like segregation of administrative duties, data encryption and key management, employee vetting process, and how they monitor their own systems for security events. You’ll need to dig in a bit and ask SAP about details of the security capabilities they have built into the platform.

Contract Considerations

At Securosis we call the division between your security responsibilities and your vendor’s “the waterline”. Anything above the waterline is your responsibility, and everything below is SAP’s. In some areas, such as identity management, both parties have roles to play. But you generally don’t see below the waterline – how they perform their work is confidential. You have very little visibility into their work, and very limited ability to audit it – for SAP and other cloud services.

This is where your contract comes into play. If a service is not in the contract, there is a good chance it does not exist. It is critical to avoid assumptions about what a cloud provider offers or will do, if or when something like a data breach occurs. Get everything in writing.

The following are several areas we advise you to ask about. If you need something for security, include it in your contract.

• Event Logs: Security analytics require event data from many sources. Network flows, syslog, database activity, application logs, IDS, IAM, and many others are all useful. But SAP’s cloud does not offer all these sources. Further, the cloud is multi-tenant, so logs may include activity from other tenants, and therefore not be available to you. For platforms and applications you manage in the cloud, event logs are available. Assess what you rely on today that’s unavailable. In most cases you can switch to more application-centric event sources to collect required information. You also need to determine how data will be collected – agents are available for many things, while other logs must be gathered via API requests.
• Testing and Assessment: SAP states that they conduct internal penetration tests to verify common defects are not present, and attempts to validate that their own business logic functions as intended. This does not extend to your custom applications. Additionally, SAP may or may not allow you to run penetration tests, dynamic application security testing, or even remote vulnerability assessment – against your applications and/or theirs. This is a critical area you need to understand, to determine which of your application security efforts can continue. Most cloud service providers allow limited external testing with advance permission, and some scans can be conducted internally – against only your assigned resources. You need to specify these activities in your contract, specifically including which tests will be performed, how permissions are obtained if needed, timeframes, and test scopes. The good news is that some of your existing application scanning responsibility is reduced, because the service provider takes care it. The bad news concerns the extra work to set up a new assessment process in the cloud.
• Breach Response: If a data breach occurs, what happens? Will SAP investigate? Will they share data with you? Who is at fault, and who decides? If federal or local law enforcement becomes involved, will you still be kept in the loop? We have witnessed cases where other cloud service vendors have not assisted their tenants with event analysis, and others where they declined to share event data – instead only confirming that an event took place. This is an area your security team needs to be comfortable with, especially if your firm runs a Security Operations Center. Because you won’t control the platform or infrastructure, your analysis is limited. This shared responsibility must be spelled out in your contract.
• Certifications: SAP obtains periodic certifications on their infrastructure and platforms. Things like PCI-DSS, ISO 9001, ISO 27001, ISAE 3402, and several others we won’t bother to list here. The key is whether SAP has the certifications important to you, and exactly which parts of their service are certified. This will give you a good idea of where their efforts ended, and where yours must pick up. Additionally, some audits only cover what the service provider listed as important – omitting items you might find relevant. We recommend you contrast their certification reports against your current certifications for on-premise systems to ensure you’re covered.
• Segregation of Duties: Remember that SAP’s admins have access to your platforms. For most cloud services consumers, who worry about admins accessing data stores, this means database encryption is needed. You will need to decide how to encrypt data and where to store encryption keys. In most cases we find the in-cloud offerings insufficient, so a hybrid model is employed.
• Data Privacy Regulations: Additional data privacy concerns may arise, depending on which data center you choose. SAP will rightfully tell you that you need to understand which laws apply to you, as both compliance and legal jurisdiction change depending on your data center’s geographic region. SAP states they adhere to German government and EU requirements for data processors, but you will need to independently verify that these meet your requirements, and develop a mitigation plan for any unaddressed items. Additionally, you need to reconsider these issues if you select fail-over data centers in different regions. Some compliance and privacy laws and requirements follow the data, but some laws will change, and there are cases where these two areas will conflict.
• Platform Updates: Cloud service vendors tend to be very agile in deployment of patches and new features. That means they have the capacity to develop and roll out security patches on a regular basis. In some cases this alters platform behavior and function.

Keep in mind that public cloud service providers like SAP don’t like what we suggest. They are not really set up to provide custom security and compliance offerings, are reluctant to share data, and don’t like to go into detail on their operations. We encourage you to ask for clarification on what the service offers, but don’t expect tailored security or compliance service. It’s set up to be on-demand, self-service, with standard pricing. Customers can have anything they want, so long as it’s already on the menu. It’s a bit like arguing with a vending machine – barter, or trying to get a Pepsi from a Coke machine, rarely works out. Cloud vendors are designed to provide a basic service, with customization being something you build on top of their basic service. Unless you spend absurd amounts of money. But custom services are atypical. This goes for general features as well as security add-ons.

You will have less control over infrastructure and no physical access to hardware. The people managing the platform don’t report to you. To compensate you will rely more on contracts, service level agreements, and audit reports from the provider on their service. Be aggressive in requesting documents on which security controls are provided and how they work; some documents are not provided to the general public. Request compliance reports to see where SAP was tested, and where they weren’t. Understand that there are many things you cannot bargain for, but you will have more success asking for data and clarification on what SAP provides. But for anything critical (and anything non-critical, too), if it’s not spelled out in the contract, don’t expect it to work the way you want or need it to.