CompTIA Security SY0-601 Exam: Basics of Cloud Cybersecurity Solutions

Objective: Given a scenario, apply cybersecurity solutions to the cloud.

Topics:
- cloud security control
- security group
- dynamic resource allocation
- instance
- virtual private cloud (VPC) endpoint
- cloud access security broker (CASB)
- next-generation secure web gateway (SWG)

This guide looks more specifically at securing components across the different service models, such as infrastructure as a service (IaaS) and software as a service (SaaS). It’s important to remember the shared responsibility model discussed Chapter 10. The focus of this chapter is on the responsibilities of the customers of IaaS and SaaS, and not on the responsibilities of the cloud service provider (CSP).
The share of responsibility changes as you get deeper into cloud services, particularly as IaaS and PaaS overlap. For example, the share of responsibility differs in Amazon Web Services (AWS) for infrastructure services, container services, and abstracted services. Keep in mind, however, that IaaS offers a great number of cloud-native controls. While they offer value-added solutions such as those related to security and compliance, many of these controls are critical configuration components to the core services offered.

Cloud Workloads
IaaS providers make it simple to instantly launch computers and containers via web services either programmatically or through a graphical interface. These elastic compute capabilities make dynamic resource allocation viable. These computer instances can be launched on demand quickly, enabling organizations to scale capacity up and down quickly. Customers pay for only what they use. Further, automatic scaling capabilities make it possible to define the circumstances that will scale the systems up or down, based on defined criteria.
Dynamic resource allocation presents two important security concerns. The first security concern involves automatic scaling of capacity. Everything done in an IaaS environment needs the proper permissions after being authenticated. This includes programmatic requests to the application programming interface (API) to scale up or down computers. Within AWS, for example, an administrator can use roles to ensure that when new instances are launched, each instance automatically receives the specified role with the proper permissions. In addition, permissions can be assigned to users to grant them specific access to the APIs that control auto-scaling.
The second security concern is that ease of use combined with the rapid capability of provisioning and deprovisioning compute services can hamper visibility efforts. Organizations need to be aware of the resources deployed, such as computer instances. All of the major IaaS providers provide dashboards and tools to provide such awareness. In addition, third-party applications are available for maintaining awareness across different IaaS cloud service providers.
Cloud providers provide administrative access to the operating system of the container instances. As with instance workloads, the customer is responsible for the security of the operating system as well as the data and the access to these workload services. The infrastructure and workloads established, maintained, and secured by the customer can be deployed in worldwide locations established by the IaaS provider. Resources are usually deployed within a virtual private cloud (VPC), which is part of a logical availability zone. The availability zones are then contained within geographic regions.

Regions and Availability Zones
Regions are separate geographic locations where IaaS cloud service providers maintain their infrastructure. Regions are located around the world, and users typically pick the region from the management console that they are closest to in order to reduce latency. There are, however, other factors to consider. Not all regions provide all services. Regions may also differ in their costs. Finally, compliance regulations need to be taken into consideration. Certain regulations, for example, may have strict data residency requirements.
Within regions are availability zones. Availability zones are isolated locations in which cloud resources can be deployed. While resources aren’t replicated across regions, they are replicated across availability zones. This, in essence, provides load-balancing capabilities. Your systems can be designed so that if they fail in one availability zone, they automatically continue to function in the others.

Virtual Private Cloud (VPC)
Rather than just launch computer resources with an assigned public IP address, an organization can deploy systems with private IP addresses within isolated spaces. This is known as a virtual private cloud (VPC), and it is essentially the networking layer in an IaaS environment. Multiple subnets may exist within a single VPC. A VPC endpoint enables a VPC to be connected with other services without the need for additional technologies such as a VPN connection or an Internet gateway. Resources in the VPC must make any requests, as the connected services are not able to initiate requests via the VPC endpoint.

A number of best practices should be followed for a VPC in a cloud environment:
- Ensure high availability of resources and cloud deployments through the use of availability zones
- Use security groups and network-based access control lists
- Use policies to control access
- Ensure central logging of API activity and use tools to monitor connections and capture traffic between your interfaces in the VPC

Security Groups
Compute instances in cloud environments typically require access to other resources, and other resources may require access to the provisioned instances. Cloud provider security groups are essentially virtual firewalls that authorize traffic to and from the compute resources. AWS, for example, automatically creates a security group for you when you launch your first instance of a computer. The following are some key points to keep in mind about security groups, particularly in terms of how they are different from traditional firewalls:
- By default, a security group only allows inbound traffic on port 22 for SSH. All other inbound traffic is denied by default.
- Traffic cannot be explicitly blocked. Traffic can only be allowed.
- Traditionally, firewalls have allowed both source and destination ports. Security groups allow only destination ports.
- Security groups are stateful. Thus, if port 80 is allowed on the way in, it is also allowed on the way out.

As a best practice, security groups should only have required ports open and should allow access only from known IP addresses and ranges.
Cloud providers also provide network access control lists (ACLs). Network ACLs, unlike security groups, are not stateful and do support deny rules. A network ACL is beneficial when you need to control traffic between subnets.
Security groups cannot explicitly block traffic. They can only allow traffic.

Policies
In the cloud, access to resources is governed by policies and their permissions. Polices are attached to an entity, which may be a user, a user group, or a role. Depending on the IaaS cloud, there may be various types of policies. Two basic policies that you should understand are identity-based policies and resource-based policies.
An identity-based policy defines the permissions regarding what a user, group, or role can do. For example, a user who needs to launch a computer instance would be assigned a policy that contains the specific permission to start a workload.
Resource-based policies, on the other hand, are attached to specific resources within the IaaS environment, and these policies define who has access and what activities they are allowed to perform.

The figure below explains the difference between identity-based policies and resource-based policies. Note that Oliver, Max, and Annie can perform some type of action on specific resources with the identity-based policies. The resource-based policies specify the particular users with access and what they can do. However, it’s very important to understand where things aren’t so clear or where there appear to be conflicts. Consider the following:



Evaluating identity-based and resource-based policies

- Oliver’s policies are straightforward. Both the identity-based and resource-based policies allow him to list and read on resource X.
- Although Max’s identity-based policy only specifies list and read on resource Y and Z, his resource-based policy on resource Y policy also grants him the ability to write. The resource-based policy on Z denies him access. An explicit deny overrides any other allowance.
- Annie is able to list, read, and write on all three resources, based on her identity-based policy. Even though she isn’t listed on any of the resource-based policies, she is allowed access to these resources and can perform the actions as she is not explicitly denied.
- Even though Trent doesn’t have an identity-based policy assigned, he is able to access both resource Y and resource Z. The resource-based policy for resource Z grants Trent full access. Resource Y grants him list and read.
By default, all access is denied unless an explicit allow permission is granted in a policy. Any explicit deny in any policy overrides any allow.

Managing Secrets
Resources that require long-term credentials such as API keys, encryption keys, and database credentials should not be hard-coded into application configuration files or buried within the source code. Cloud providers and third parties provide systems for managing secrets. For example, AWS’s secrets management service, Secrets Manager, works with the built-in AWS Identity and Access Management (IAM) policies that allows people and systems to retrieve passwords only when they need them and under the right circumstances. Secrets management protects and manages access to the applications and services. All secrets are encrypted at rest and in transit.

The figure below illustrates a scenario in which a custom application requires access to a database. The credentials to access the database are stored in the secrets management service. 



Using a secrets manager for application access to a database

The administrator creates the credentials on the database that the application will use.
The administrator stores the credentials in the secrets management system. The credentials are stored as a named secret (such as App-DB-Secret).
When the application accesses the database, the application makes a call to the secrets manager for the named secret (App-DB-Secret).
The secrets management system decrypts App-DB-Secret and securely transmits the credentials to the application (not the database) by using transport layer encryption.
The application uses the credentials received to access the database.
In the example illustrated in the figure, after steps 1 and 2 are complete, the secrets manager can manage the task of rotating the secrets and programmatically managing retrieval based on API calls. Meanwhile, the secrets manager provides audit details of all access and any configuration changes.

Central Logging
Maintaining proper control and management over logging is important with security monitoring and auditing. Infrastructure, applications, and services deployed in cloud environments should be aggregated to a central logging facility. The major IaaS cloud providers provide logging for all activities, using their APIs as the services interact. These events should then be written to a storage location in the cloud service provider. These centralized logs can be used for further inspection and analysis in other IaaS-based security and monitoring systems or integrated with any SIEM solution or service, such as those offered by Sumo Logic.

AWS provides AWS CloudTrail, which can be written to an S3 storage bucket designed as a log archive. CloudTrail and other similar services provide the ability to maintain a history of API calls across an IaaS account. This history includes when an API was called and what user called and the source IP address. At a minimum, you should log the following in a cloud environment:
- Privileged account actions taken on any and all resources
- Access to the audit trails and storage
- All authentication attempts both successful and unsuccessful
- Create and delete events for all resources and objects across the infrastructure
The three major IaaS cloud service providers are Amazon, Google, and Microsoft. Their platforms are known as Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. While AWS got a huge head start, the others have quickly caught up in terms of functionality. The three providers offer similar services, but the terminology differs slightly across the three providers.

A Comparison of Terminology Across the Three Major IaaS Providers

Third-Party Cloud Security Solutions
While IaaS cloud service providers offer robust cloud-native security solutions, there are gaps. Third-party offerings can fill these gaps and complement IaaS security services. These solutions provide critical capabilities that are typically not provided by IaaS cloud service providers.
A cloud access security broker (CASB) traditionally provides security services for Software as a Service (SaaS) applications. However, CASBs along with next-generation secure-web gateways (SWGs) provide the capability to deliver static and dynamic access to the management plane of IaaS providers, just as they do any SaaS app. Policies may, for example, simply deny access, or policies may dynamically prevent access based on other telemetry and attributes (for example, where the user is located and the user’s current threat profile). Software-defined perimeter (SDP) solutions can also broker similar access beyond the management plane down to the specific applications running on cloud workloads. Many of these capabilities are being combined as a solution stack under the Secure Access Service Edge and Zero Trust monikers.

Each of the major IaaS cloud providers offers a marketplace or an app store, from which many of these and other security-related solutions can be deployed. AWS, for example, groups third-party solutions based on either structural or situational awareness. Structural awareness solutions help manage risk and apply protections to systems and data. They include the following:
- Cloud compliance and best practices: Visualization and continual assessment of the environment, including the ability to enforce known good standards
- Instance and container visibility: Monitoring and protection of containers through their life cycle
- Virtual private network: Secure access to applications running in a VPC for remote employees
- Secure data: Encryption and key management solutions to protect data and meet regulatory compliance standards
- Vulnerability assessment and management: Visibility into the attack surface to discover and resolve security issues
- Software composition analysis: Management and security for open-source licenses
- Operational intelligence: Aggregation and correlation for the analysis of data across security, performance, and availability
- DevSecOps: Automated and continuous process management for continual integration and delivery of secure applications
- Cyber risk management: Prioritized insight into the threats, vulnerabilities, and impacts of cloud assets

The situational awareness solutions detect security events and are capable of responding, recovering, and helping with continual improvement. They include the following:
- Firewalls and proxies: Provide fine-grained inspection of traffic for potential threats at both the network and application levels
- Endpoint detection and response: Protect endpoints, including cloud workloads from zero-day and other attacks
- Intrusion detection systems: Monitor networks and workloads for security events
- Backup and restoration: Protect data from errors, failures, and accidental deletion
- Disaster recovery: Provides additional flexibility to quickly recover from a disaster, ensuring that cloud workloads are available
- Security information and event management: Ingests, correlates, and prioritizes events for deeper visibility into anomalous behavior and threat mitigation
- Workload isolation: Provides dynamic security control for microservices, containers, and other workloads

Quiz:
1. A user does not have an identity-based policy and requires access to a storage resource but is denied access. Which of the following do you need to do in order to allow him access? A. Assign an identity-based policy to the user to allow access B. Assign an override for any deny attribute in the identity-based policy C. Remove the deny from the resource-based policy D. Change the deny to an allow permission on the resource-based policy
2. You need to block SSH inbound traffic on a virtual instance. Which of the following would accomplish this goal? A. Assign an explicit inbound block rule for port 22 on the security group. B. Assign a resource-based policy on the instance to block port 22. C. Remove the inbound allow rule from the security group for port 22. D. Remove the resource-based policy on the instance allowing port 22.
3. Which of the following allows a VPC to be connected with other services without the need for additional technologies such as a VPN connection or an Internet gateway? B. SWG C. VPC endpoint D. DevSecOps

Answer 1: D. An explicit deny prevents access and overrides any allow statement. The deny needs to be removed. Because the user doesn’t have an identity-based policy, the allow permission on the resource also needs to be granted. Answer A is incorrect because the explicit deny still overrides the allow. Answer B is incorrect, as explicit denies take precedent and there is no such option for an override attribute. Answer C is incorrect, as by default without any policies assigned, the user does not have access.
Answer 2: C. Remove the inbound rule that allows port 22 from the security group. This rule is enabled by default. Security groups do not block traffic. They only allow specific traffic, so answer A is incorrect. Finally, resource-based policies do not pertain to network traffic, so answers B and D are incorrect.
Answer 3: C. A virtual private cloud (VPC) endpoint allows a VPC to be connected with other services without the need for additional technologies such as a VPN connection or an Internet gateway. Resources in the VPC must make any requests, as the connected services are not able to initiate requests via the VPC endpoint. Answers A and B are incorrect because cloud access security brokers (CASBs) along with next-generation secure-web gateways (SWGs) provide the capability to deliver static and dynamic access to the management plane of IaaS providers, just as they do any SaaS app. Answer D is incorrect because DevSecOps involves automated and continuous process management for continual integration and delivery of secure applications.