 Hi, everyone, and welcome to our talk. Adopting cloud computing models could be a blessing or a curse. When done with security and compliance in mind, it could save you lots of time, effort, and operational costs. When done without regard to security and compliance, it could result in exposing your company to financial and reputational risks. In this lightning talk, we will focus on the cloud-cheered responsibility model and how to leverage it to your advantage. I'm Antrug Asaf. A senior development manager on the IS public cloud team at IBM. And I'm David Laboch, an IBM-distinguished engineer focusing on data and AI software as a service. Many of us are hard-draining to cloud and want to concentrate on getting value and not spending valuable resources on supporting functions of our workloads. We outsource where we can benefit. Though, on this journey to cloud, one needs to rethink roles and responsibilities for securing workloads and data. In a traditional on-premise environment, we have full control and responsibility for securing our workloads. Yet this is not the case if we move our workloads to the cloud. Cloud security roles and responsibilities differ based on cloud delivery model you use, whether it's IS, PAS, SAS, or even a combination of them. Two main stakeholders mentioned on the European General Data Production Regulation, UDPR, are controllers and processors. The controller is typically the customer acting as a data controller for any personal content they have on their cloud environment and determining the purpose and means for processing of personal data. The processor typically is the role of the cloud service provider, processing personal data on behalf of the controller. Eric, a good example is the responsibility over securing privileged access to cloud workloads. Managing privileged access to sensitive data is a shared responsibility between the processor and the controller of the data, as defined by GDPR. However, in the survey shown here, an alarming 60% of organizations incorrectly view the cloud provider as being the solely responsible for securing privileged access to cloud workloads. If you read your agreement with your cloud provider, you'll find that this isn't true. It's shocking how many public cloud customers are assuming that the cloud service providers can completely protect their customized, highly individualized cloud workloads. During cloud migrations, the majority of the company surveyed stated that they overlooked the shown above security controls relating to privileged access. To defend against breaches and adverse apportion of shared responsibility models, organizations need to establish security practices and use security tools that are purpose-built for cloud security. The shared responsibility models are one of the least understood but most impactful components of cloud risk management, according to the cloud security aligns. The root cause of many security incidents is an assumption that the cloud provider is handling something when it turns out nobody's handling it. In his book, Practical Cloud Security, Chris Dustin explains the shared responsibility model using the analogy of eating pizza. The traditional on-premise world is like making pizza at home. You buy lots of different components, make a dough, assemble the pizza yourself. It takes effort, but you get complete flexibility. When you use the infrastructure as a service, though, the base layer is already prepared for you. You add whatever you need to add, bake it yourself, and you're responsible for these things. When you move up to platform as a service, more decisions are baked for you and you just use that base as part of developing your end solution. With pizza as a service, you're hungry for pizza. You can just go sit down at a restaurant and order a pizza. Sometimes it can be difficult to categorize a service as IS or PAS and they're growing together in many cases. The exact classification isn't important. What's important is that you understand what a service provider does and what your responsibilities are. When you get to software as a service, it might seem like everything's done for you. It is not. You still have the responsibility to eat safely and although some might disagree, but the restaurant should not be responsible if you choke on your food. In SaaS world, this largely comes down to managing access controls properly. The reality of cloud computing is unfortunately a little more complicated than eating pizza in their some gray areas. At the bottom of the diagram, things are concrete, often literally. The cloud provider has complete responsibility for physical infrastructure security, which often involves controls beyond what companies can reasonably do on premises, such as biometric access with anti-tailgating measures, security guards and similar controls to keep unauthorized personnel out of the physical facilities. Some cloud providers offer the option of running workloads on dedicated hosts or a higher cost, of course. If you choose to run on a multi-tenant virtualized environment, the security controls keeping your virtual environment separate from other customers' virtual environments are the provider's responsibility. When the spectra and meltdown vulnerabilities came to light in early 2018, one of the potential effects was that the users in one virtual machine could read the memory of another virtual machine on the same physical computer. For IS customers, fixing that part of the vulnerability was the responsibility of the cloud provider, but fixing the vulnerabilities within the operating system was the customer's responsibility. Network security is shown as a shared responsibility as there are several layers of networking and the responsibility for each slice with a different party. The cloud provider has its own network that is its responsibility, but there's usually a virtual network on top, and that's the customer's responsibility to carve up into reasonable security zones and put the proper access controls and rules around them. Many implementations also use overly networks, firewalls, transport encryption that are the customer's responsibility. Operating system security is usually your responsibility if you're using IS, and it's the customer's, sorry, the provider's responsibility if you're purchasing platform or software services. In general, if you're purchasing those services, you have no access to the underlying operating system. As a general rule of thumb, if you have the ability to break it, you usually have the responsibility for securing it. Middleware in this context is a generic name for software such as databases, application servers, or queuing systems. If they're in the middle between the operating system and the application, they're typically not directly used by end users, but used to develop solutions for end users. If you're using a pass, middleware security is often a shared responsibility. The provider might keep the software up to date, but you retain the responsibility for securing relevant settings such as encryption. The application layer is what the end user actually uses. If you're using SAS, vulnerabilities at this layer, such as cross-site scripting or a SQL injection, are the provider's responsibility. Even if all of the other layers have bulletproof security, a vulnerability at the application security layer can easily expose all of your information. Finally, data access security is almost always your responsibility as a customer. If you incorrectly tell your cloud provider to allow access to a specific data set, such as granting incorrect storage permissions, middleware permissions, or SAS permissions, there's really nothing the provider can do. Many real-world examples of security incidents stem from poor understanding of the shared responsibility model, and came from object storage buckets. Even if the storage solution you use is secure and encrypted, it wouldn't help if you don't set your access controls properly. This misunderstanding has caused the loss of data on 198 million U.S. voters, auto-tracking company records, wireless customer records, over 3 million demographic survey records, and over 50,000 Indian Citizens Credit reports. What is the waterline of the iceberg of your workload? We hope you found our introduction of the shared responsibility model useful as a tool to assess and classify your responsibilities for your workloads. We would love to stay in touch. Please find us on LinkedIn and enjoy the rest of the conference.