In addition, you must consider unique factors when conducting cost benefit analysis to determine whether moving to the cloud makes sense for your organization.
Cloud Secure Data Lifecycle
I often use the phrase “security follows the data” when describing data security. What I mean by this phrase is that keeping data secure requires an understanding of where the data is, both physically and in its lifecycle. The figure shows the cloud secure data lifecycle, and its steps are described in the following list.
Cloud secure data lifecycle.- Create. Data is either generated from scratch or existing data is modified/updated.
- Store. Data is saved into a storage system or repository.
- Use. Data is processed by a user or application.
- Share. Data is made accessible by other users or systems.
- Archive. Data is transferred from readily accessible storage to a more long-term, static storage state.
- Destroy. Data is deleted and removed from storage, making it permanently inaccessible and unusable.
Cloud based disaster recovery (DR) and business continuity (BC) planning
This section gives you some tips, as a CCSP candidate concerned with business continuity planning and disaster recovery in cloud environments. Some important points to consider are- Understand how the shared responsibility model applies to BCP/DR.
- Understand any supply chain risks that exist (for example, vendor or third-party factors that may impact your ability to conduct BCP/DR activities).
- Consider the need to keep backups offsite or with another CSP.
- Ensure that SLAs cover all aspects of BCP/DR that concern your organization, including RPOs, RTOs, points of contact, roles and responsibilities, and so on.
Service Level Agreements are tremendously important to consider when planning for business continuity and disaster recovery. SLAs should clearly describe requirements for redundancy and failover, as well as address mitigating single points of failure in the cloud environment. In addition, you should look for clear language on your ability to move to another cloud provider should your DR and BC requirements not be met. While having all of this documented and agreed upon is a must, it’s also important that you periodically review and test that these agreements continue to hold true.
Cost benefit analysis
Any organization considering moving to the cloud should first conduct a thorough cost-benefit analysis to determine whether the features offered by the cloud justify the costs associated with migrating and maintaining a cloud environment. The following list identifies some factors worth considering, but organizations’ individual cost-benefit analysis may differ, based on their own requirements:- Steady versus cyclical demand: One of the essential characteristics of cloud is rapid elasticity. Companies who see cyclical demand stand to benefit the most from cloud computing. Think of a retailer that sees demand go up and down, based on seasonal changes and holidays. When these types of customers own and operate their own data centers, they must purchase and maintain enough resources to support their highest capacity periods (Black Friday, for example). During other times of the year, these customers are still paying to operate facilities that are likely only a fraction in use. Some organizations, however, don’t experience cyclical spikes, and so the equation for them is a little different. Every potential cloud customer must evaluate their own demand trends and determine whether cloud computing offers a financially attractive option for running their workloads.
- CapEx versus OpEx: One of the biggest changes for companies moving to the cloud is a drastic shift from capital expenditures to operational expenditures. Rather than paying to keep data centers up and running, companies in the cloud carry OpEx costs associated with cloud oversight, management, and auditing. Organizations must evaluate whether their current org structure, business model, and staffing can support this shift. For example, some companies may realize that their current staff is not sufficiently equipped to take on new roles, and the costs of hiring new personnel may be prohibitive to moving to the cloud.
- Ownership and control: Organizations who own and operate their own hardware maintain full ownership and control over their systems and data; they get to change what they want, when they want. When moving to the cloud, some of this control is traded for convenience and flexibility. While organizations can negotiate favorable contractual terms and SLAs, they will never maintain the same direct control they have with on-prem solutions. While many customers are willing to make this tradeoff, each organization will have to assess their own priorities and determine whether relinquishing some level of control is acceptable.
- Organizational focus: One of the key benefits of cloud is the fact that organizations can shift their focus from operating systems to overseeing their operation; a difference that can be significant and allow organizations to focus more on their core business rather than managing IT operations. While this benefit is clear, some organizations may not be completely ready to transition their existing operations staff into other roles. Business leaders must evaluate how ready they are for such an organization shift and whether the pros outweigh potential pitfalls.
Security considerations for different cloud categories
Each cloud category (IaaS, PaaS, and SaaS) will share some similar security concerns, but some considerations will be unique to each category due to the varying levels of responsibility shared between the CSP and customer.IaaS security concerns
Due to the nature of IaaS architectures and services, virtualization and hypervisors play a key role as attack vectors, though other security considerations do exist.Some key IaaS security considerations include
- Colocation and multitenancy: With on-premise solutions, organizations can be certain that their data is physically separate from anyone else’s data. In cloud environments, an organization must assume that they share resources with dozens, hundreds, or even thousands of other organizations. While it is up to the CSP to logically (or virtually) segregate one tenant’s data from another, it is the responsibility of each customer to protect the data they deploy in accordance with any regulatory or contractual requirements they may have.
- Virtual machine (VM) attacks: Active VMs are susceptible to the same security vulnerabilities as physical servers — and whether active or offline, a compromised VM poses a threat to other VMs that share the same server. This risk is because VMs that reside on the same physical machine share memory, storage, hypervisor access, and other hardware and software resources. The CSP is responsible for preventing, detecting, and responding to malicious activity between VMs.
- Hypervisor attacks: Compromising the hypervisor can be considered a gold mine for attackers. An exploited hypervisor can yield access to the physical server, all tenant virtual machines, and any hosted applications.
- Network security: Cloud environments rely on virtual networks that contain virtual switch software that control the movement of traffic within the cloud. These switches, if not properly configured and secured, can be vulnerable to layer 2 attacks, such as ARP poisoning. Because customers do not have the level of control over the network as they would with on-prem solutions, it is up to the CSP to tightly control network activity and be transparent with the customer (within reason) about how their data is protected.
- Denial of service (DoS) attacks: DoS attacks are a threat in both cloud environments and traditional data center environments. The nature of cloud and the sheer size of many CSPs may make it more challenging to take down a cloud service, but it’s certainly not impossible. If one cloud customer is experiencing a DoS attack, it can potentially impact other customers on the same hypervisor. Even though hypervisors have mechanisms to prevent a single host from consuming 100 percent of a system’s resources, if a single host consumes enough resources, it can leave insufficient compute, memory, and networking for other hosts.
PaaS security concerns
PaaS services being platform-based, rather than infrastructure-based, present a different set of security considerations.Some key PaaS security considerations include
- Resource isolation: PaaS tenants generally have extremely little to no system-level access of the underlying environment. This assures resource isolation, and prevents a single customer from impacting multiple customers with infrastructure- or platform-level configurations. If a customer is able to change underlying configurations within the environment, it can negatively impact other customers that share resources, as well as make it very hard for the CSP to effectively manage and secure the environment.
- User permissions: It’s important that each tenant in the PaaS environment is able to manage their user permissions independently. That is, each instance of the PaaS offering should allow the respective cloud customer to configure their own user-level permissions.
- User access management: Cloud security professionals must evaluate their organization’s business needs and determine what access model works for them in the cloud. It’s crucial that you find the balance between allowing quick user provisioning with proper and secure authentication and authorization. Cloud environments offer a great deal of power to automate these tasks, thanks to elasticity and autoscaling.
- Malware, backdoors, and other nasty threats: Autoscaling means that anytime there’s a backdoor or other piece of malware within a cloud environment, it can grow and scale automatically without intervention from a cloud security professional. In addition, these threats can start with one PaaS customer and rapidly expand to other customers, if not detected and eradicated. It’s up to the CSP to continuously monitor for new vulnerabilities and exploits, and it’s the customer’s job to use secure coding best-practices.
SaaS security concerns
SaaS presents very different security concerns from its infrastructure and platform peers. While most of these concerns will fall on the CSP, it’s important that you are familiar with some key SaaS security considerations:- Data comingling: The characteristic of multitenancy means that multiple customers share the same cloud infrastructure. In SaaS deployments, many customers are likely to store their data in applications with shared servers, storage, or even potentially shared databases. This comingling of data means that any cross-site scripting (XSS), SQL injections, or other vulnerabilities can expose not one but potentially all customers in the shared SaaS environment. It’s up to the CSP to ensure that customer data is segregated as much as possible, through use of encryption and other technologies. In addition, the CSP is responsible for conducting vulnerability scans and penetration testing to identify and fix weaknesses before they are exploited.
- Data access policies: When evaluating a SaaS solution, you should carefully consider your organization’s existing data access policies and evaluate how well they align with the cloud provider’s capabilities. Again, multitenancy means that several customers are sharing the same resources — so the level of data access configuration and customization is potentially limited. As a cloud security professional, you want to be sure that your company’s data is not only protected from other cloud customers, but you’ll also want to ensure that you’re able to control access between different users within your own company (separate access for developers and HR, for example).
- Web application security: SaaS applications, by nature, are connected to the Internet and are meant to be available at all times. This interconnection means that they are constantly vulnerable to attacks and compromise. Because cloud applications hang their hat on high availability, any exploit that takes down a web app can have a great impact on a cloud customer. Imagine if an organization’s cloud-based payroll systems suddenly went down on pay day!