Identifying cloud threats

- [Instructor] Proper cloud governance begins by identifying any potential threats related to the use of cloud computing services. This can be done when you're planning cloud adoption if it's not already in use or after the fact and this matter of fact it should be revisited periodically. One way to deal with potential threats in the cloud is to adopt some kind of a framework that will categorize and identify any threats that might be related to the use of cloud services. So a cloud adoption framework or CAF might begin with looking at cost management, having security baselines for the configuration of cloud resources, ensuring resource consistency, having an identity baseline and having deployment acceleration to minimize the amount of time it takes to deploy cloud solutions whether they are security related or not. Let's go into each of these in a little bit more detail, starting with cost management. When we talk about cost management, we have to in the cloud, distinguished the difference between OPEX and CAPEX. Operating expenses or OPEX are what we're talking about in terms of monthly recurring charges related to the use of cloud computing whereas CAPEx or capital expenditures would be related to the expenditure of funds required to get equipment up and running on premises to host your own services instead of doing it in the cloud. So cost management also means that cloud technicians need to be aware of shutting down or deleting unused resources when they're no longer required such as if virtual machines need to be suburban up for a short period of time, perhaps only for dev testing. Cloud technicians can also take a look at using spot or reserved instances. Spot instances are the use of extra compute capacity available in data centers at a reduced cost. However, it is not guaranteed. In other words, if you deploy spot instance virtual machines or databases in the cloud, they are not guaranteed to be up and running 24/7. So not good for mission critical workloads. Whereas reserved instances are a little bit different in that you are paying upfront for compute capacity for a period of time, such as one year up to three years and you do this because you can realize a large discount than if you just paid on demand as you used that compute service. So we should also think about enabling spending limits or budgets so we get notified when our cloud competing charges per month reach a certain limit because if we have a compromised cloud account, a hacked cloud account, then the malicious user that is in control of the account could incur significant charges and they might do that because they are spawning multiple virtual machines for Bitcoin mining or for initiating distributed denial of service attacks against other victims and so on. So that's one aspect of a cloud adoption framework. Another is a security baseline. Having a security baseline really is effective only if you have an up-to-date resource inventory. A resource might be a virtual machine. it might be a storage account. it might be a database, a website, anything that would be deployed in a cloud computing environment. So we want to have up-to-date inventories of what is out there in our cloud account and how it's configured. Now there are baselines that we might build that are built from scratch. Custom baselines on what we want the configuration to look like for virtual machines, for web apps, for databases. There are also baselines that we might even be able to import depending on the cloud provider we're using that align with industry standards or regulatory baselines for security configurations. An example would be if you need to be PCI DSS compliant because you're dealing with credit card holder information then there are baselines on what kind of a configuration that would entail in a particular cloud provider environment. We also should think about identity and access management or IAM configuration vulnerabilities such as using weak passwords or maybe not limiting from which IP addresses users must be authenticated. Also missing patches for things like virtual machines or lack of encryption for data at rest. All of these are potential threats that we can deal with if we have a proper cloud adoption framework that is adhered to. Resource consistencies, is the next part of a cloud adoption framework. This means we have to have our cloud resource inventory, once again, we have to know what's out there and we should have consistency in many ways including the naming of cloud resources. So imagine if cloud technicians are deploying a lot of virtual machines frequently and calling them whatever they want without any thought to consistency becomes very difficult to go through those virtual machines to determine what's important, what's not, what should be removed, what should be left running and so on. We can also ensure consistency when it comes to not only the names of resources but their configurations by deploying those resources from templates. Templates essentially have the instructions of how to deploy one or more resources. And this is great because it allows for resource consistency in the configuration. We also can detect when we have a configuration that has drifted from the template definition and that might trigger an alert because it might be a security vulnerability that's been opened up with a reconfigured setting that differs from what existed in the original template. So we can use templates also to quickly redeploy resources to a specific configuration state. And so it can lend itself well to disaster recovery. An identity baseline is based on a directory service where we have users and groups that are defined. We could have a cloud-based directory services, an on-premises directory services configuration and we might even link them together. Don't even have to do that through a VPN tunnel. You can do it straight over the internet. Now the benefit of linking a cloud and on-premises directory service is that users that are already familiar with their on premises credentials can continue to use them to access cloud-based applications. We're talking about identity and access management or IAM users and groups. One way to mitigate some threats related to user sign in security is to enable multifactor authentication or MFA. So besides your username and a password, a cloud user might have to enter in a code that sent us a text message to their mobile device or sent to their email account, something along those lines. Role-based access control or RBAC is also an important part of an identity security mechanism in the cloud where we can delegate permissions for example to cloud technicians so they only have access to certain resources. So if I want to use role-based access control to limit a cloud tech to only create virtual machines in a certain location, then we could do that using role-based access control. Finally, with the cloud adoption framework another consideration would be deployment acceleration. This really means automation. Now we've mentioned templates that essentially contain the instructions to deploy cloud resources. The case of a Microsoft Azure environment, that's called an ARM template and an Amazon web services it's called a CloudFormation Templates but the concept is the same. We have instructions that are used to deploy or configure one or more cloud-based resources. So we can harden those templates so that when resources are deployed or configured that they are done in such a manner that we have security settings or security baselines that we are adhering to for the organization. You could have scripts to automate the deployment or configuration or management of cloud resources that can also be hardened. You can harden pre-configured images that you might use to deploy new virtual machines in the cloud that might make sure that we have a security compliance in place within those images already. We can also ensure that we are using managed services in the cloud where it makes sense. A managed service means that we don't have to worry about the underlying infrastructure like deploying virtual machines or patching them that's handled by the cloud service provider. That would free us up then to focus on what we're trying to solve using the technology and to make sure that it's hardened.