Cloud Computing Is the New Black 

Part 3 of 3: Security in The Cloud 

Read Part 2 of the Cloud Computing is the New Black series

Security in Cloud computing starts with creating a risk management strategy. A risk management strategy is a plan to access and manage risks associated with Cloud computing. There are five main areas of the risk management process. 

1. Identify the risk. The project management team and stakeholders are responsible for completing a thorough evaluation of all aspects of the project to identify possible risks that might affect the outcome. Once again, the Project Management Book (PMBOK) methodology should guide this process. This is the step where the team creates a project risk register. The register is a detailed listing of the identified risks, owners, and possible mitigation measures (Kloosterman, 2018). 
2. Analyze the risk. After risks are identified, the team will determine the likelihood of their occurrence and the consequences of their impact on the project. This information is used to further expand and flesh out the project risk register. 
3. Force rank the risk. In an ordered list. This is where the risks are ranked by the magnitude of their impact on the project. Does the risk completely shut down the project progress? If so, it is classified as a major risk. Does the risk have minimal impact on operations? In this occurrence, it is classified as a minor risk. This force ranking helps the team understand where to better focus their time. 
4. Treat the risk. Now that the major risks have been identified, it is time to plan to modify the risk to achieve an acceptable outcome. Risks are treated by creating detailed risk mitigation strategies and contingency plans to recover after risks have happened. Risk treatments are added to the project risk register to complete the process.  
5. Monitor and review the risk. The project risk register can be used to monitor the risks and keep the team prepared to act in the event a risk happens.  

Security in Cloud computing is also about restricting access to Cloud resources to authorized personnel. A new security best practice model has been introduced in Cloud Computing called the Least Privilege Security Model. In this model, the system administrators grant users the least access permissions possible to perform the task at hand. In this model, privileges are controlled at a micro access level.  

For example, with Amazon Web Services, the administrator grants the user access via policies and roles. Policies control which of the permissions – read, write, or list – are enabled. Roles further bracket the permissions by providing the user with temporary permissions. The temporary permissions are only available for a specific time. After that time, the role expires and the access is removed. Roles are granted and can be immediately revoked by administrators. 

The Least Access Privilege model gives administrators the power to expose risks and better defend against threats to protect their applications and data. 

Cloud Computing Responsibility Model 

One of the big differences between Cloud and on-premise solutions is the owner of the solution. In on-premise installations, the company most likely is the owner of the solution from the hardware to the purchasing and holding a license for their business applications. In Cloud solutions, the Cloud Service Provider (CSP) is the owner of the infrastructure and many of the applications and tools that are used to manage the Cloud installation.  

Cloud computing brings with it a new paradigm of shared responsibility for the IT infrastructure. Cloud Computing services share the responsibility of the online product or solution architecture with the customer. There is no one all-encompassing view of this shared responsibility model. AWS, Azure, and Google Cloud all offer differing SLAs that cover their service delivery models. The picture below [figure 1} presents a good general overview of how the responsibility model is applied across SaaS, PaaS, and IaaS service models.  

The SaaS model is the most common deployment model today and represents the case when the CSP takes on the highest security level. Since the end-user is simply a customer of the online application (e.g., QuickBooks Online), they have no control of or even visibility into any aspect outside of the application, and therefore no responsibility should be required of them.  

The PaaS model is the next level of shared responsibility. In the PaaS model, the customer is responsible for the Presentation Layer, API layer, All Applications, Data, Metadata, and Content. This means that the CSP is responsible for the middleware and developer tools suites that deliver those CSP-provided services.  

The IaaS model is the model with the least responsibility falling on the CSP. In this model, the customer is responsible for much of the cloud application or solution. The CSP is responsible for the Core connectivity and uptime delivery, hardware layer, network layer, and physical facilities. The IaaS model is best reserved for organizations with expert level certified Architecture and Support teams available to design, build, deploy and maintain its operations. 

The key reason to establish these clear lines of responsibility for CSPs and customers is to ensure that clear boundaries are in place for all to understand and adhere to. The overarching SLA remains the go-to document for any questions about this shared security model.  

David Bankston
Chief Technology Officer, True Elements