Today, most of the solutions and applications are migrated to cloud platforms. All the cloud service providers (CSP) employ a shared responsibility model. This means the cloud providers are responsible for the security “of the cloud” and the customers are responsible for the security “in the cloud.” Based on research it is stated that 95% of cloud security breaches are because of user misconfigurations. Cloud security almost entirely depends on the consumers configuring and using the cloud platform. Thus, it is important to understand the threat landscape of cloud implementations, the risks involved, and ways to remediate them. One of the earliest and most important processes is threat modeling. This process helps in analyzing the cloud architecture, identifying security threats, evaluating risks, and prioritizing remediation efforts. This chapter describes how to apply some of the popular threat modeling frameworks to access cloud architectures.
TopCloud Computing Security Threats
The Cloud Security Alliance (CSA) (2022) recently published its annual report on cloud security top threats. The CSA working group surveyed over seven hundred experts and professionals in the cloud security domain to prepare this report. Below is the list of top cloud security threats in the order of significance:
Insufficient Identity, Credentials, Access, and Key Management
Access to cloud resources and services is provided by authenticating and validating the identity of the users. Identities are not only assigned to users but also to services like virtual machines, storage systems, databases, serverless functions, containers, and other resources. It is important to always follow the least privilege and zero trust policies. Frequent gap analysis should be performed to compare what permissions the users/roles are assigned versus what is really required so that unnecessary permissions can be removed. The service/client credentials, secrets, keys, and tokens should never be hardcoded in config files and client-side code. They must be securely stored and managed using cloud-native services like AWS Secrets Manager, Azure Key Vault, and CyberArk. These credentials and secrets should be frequently rotated as per the organization's IT policies.
Insecure Interfaces and APIs
Application Programming Interfaces (APIs) facilitate communication between applications and services. APIs are prone to several security exploits due to misconfigurations, broken authentication, improper access control, insecure coding practices, and lack of encryption. Application developers need to implement security controls like input validation, rate limiting, integrity validation, security headers, access controls, and sufficient logging and monitoring. Strong authentication methods like OAuth2 or mutual TLS should be implemented. APIs should use HTTPs with TLS version 1.2 or above. Internal APIs should not be exposed to the internet and must be restricted using appropriate security groups.
Misconfiguration and Inadequate Change Control
It’s very easy to spin up new cloud services and resources like virtual machines, databases, and container nodes based on demand. However, this flexibility may lead to misconfigurations and security vulnerabilities. Services can be launched, replicated, and distributed in minutes and if there are any vulnerabilities or misconfigurations in the base image, it will be repeated throughout. Teams may spin up new servers or databases and continue to reconfigure them based on specific requirements. However, it is very difficult to keep track of all the changes in the whole infrastructure. It is the responsibility of the customers to keep track of what resources are used, how they are configured, and the history of all configuration changes made. Frequent configuration scans should be performed to detect any errors as the cloud environment and the threat landscape are ever-changing.
Lack of Cloud Security Architecture and Strategy
Every organization should publish cloud security guardrails that can be followed by all the application teams. The guardrails and policies should clearly define the responsibilities of the developers in securing the cloud deployments. The guardrails should highlight policies around principles of least privilege, encryption of data at rest and in transit, principles of separation of duties, sufficient logging and monitoring, server hardening requirements, network security, and establishing of segmented VLANs using firewalls to limit damage during an exploit.
Insecure Software Development
There are several options available for developers to build an application. They can use SDKs, and browser extensions, download code from public Git repositories, use containerized packages to deliver applications, and access cloud-based SaaS CI/CD tools to build, test, and deploy applications. All organizations should define and mandate Secure Development Lifecycle (SDLC) standards. If the development tools and processes are not properly defined and securely configured, it may lead to several security vulnerabilities.