A Checklist for Strengthening Cloud Security Posture

Improving the cloud security posture consists of a set of policies, controls, procedures, and technologies that need to work together to protect an organization’s cloud-based assets.

From authenticating access to filtering malicious traffic, cloud security posture can be configured and made better to the exact needs of the business. With the emergence of Cloud Security Posture Management (CSPM) technologies, the cloud platform-specific rules can be orchestrated centrally reducing administration overheads.

The way cloud security can be delivered varies on a couple of factors:

1. How an organization has architected the business requirements in the cloud?
2. Cloud platforms – SaaS, PaaS and IaaS in use
3. Shared responsibility between an organization (cloud subscriber) vs cloud provider

Most of the cloud security discussions and implementations depend on the cloud provider or the available cloud security solutions in place (also security solutions which can be extended to the cloud). 

However, the implementation of cloud security processes should be a joint responsibility between an organization and the cloud service provider. A significant portion of any business also depends on cloud storage, communications, or infrastructure. Therefore, protecting the crown jewels in the cloud should be a key priority. 

Cloud Security Architecture and Must Have’s

With the basics in place, let’s talk about the role of cloud security architecture. It essentially defines the design principles and best practices that need to be in place when building out a cloud environment. To establish what design principles, need to be in place – it is important to determine the potential threat vectors at each layer of the cloud environment or the cloud-related deployments. The following lists a high level limited list of threats that we see across most of the cloud-based deployments:

IaaS: All threats listed in OWASP top 10, VM weakness exploitation, VM Isolation failure, DoS/DDoS, and Data leakage.

PaaS: In addition to threats faced at the IaaS layer, Privilege escalation, compromised authorization

Note that the above list is not exhaustive and only lists common threats we periodically see in a public cloud environment.

To mitigate the above threats and to define the minimum security checklist or design principles, an organization should be able to have a crisp cloud security architecture in place. Covering a wide range of security architecture patterns is beyond the scope of an answer to one question, but we have defined the basics principles and 8 “must-haves” that would help you mature your organization’s security posture, to a better state:

1. Encrypt Everything:  It is highly recommended to scan for unencrypted data (EBS, DBs, S3) and unencrypted transit (Security Groups with non-SSL ports). In addition, have a key management practice in place with automated rotation for encryption keys on a schedule/periodic basis.
2. Use Least Privilege: Always a best practice to never use root accounts. Enable Multi-Factor Authentication for privileged users and reduce permissions to those needed for everyday tasks (following the principle of least privilege). Do not create IAM policies that allow full “*:*” admin privileges and ensure IAM policies are attached only to groups or roles.
   
   Identities should be planned, governed, and implemented in an automated manner, based on the organization’s user management practices (pertaining to the business requirements). It is recommended to leverage Single Sign-on (SSO) tools for their integrations across cloud platforms. The principle of least privilege needs to be in place for any deployment related to the provisioning/enabling user’s access to services. Similarly, users that are no longer part of the organization should be de-provisioned as soon as possible via automation.
3. Embrace Infrastructure as Code: It is recommended to leverage automation tools to harden images and implement industry standard (e.g., CIS) hardening baselines. In addition, scan code repositories for hard-coded passwords, secrets, and other credentials via SAST/DAST techniques.  Ensure “grandfathered” apps do not “lift and shift” into the cloud without the security team’s review.
   
   For any deployments, application-related configurations and associated firewall policies should be automated with APIs where possible, considering the fundamentals for API security. When provisioning networking resources such as load balancers, gateways, compute nodes, firewalls, SSL Certificates, etc., automate their configuration where possible, with proper security policies.
4. Control Remote Access: Define network boundaries for isolation (+ segmentation) and wherever possible, leverage bastion host for remote access, and configure security groups to deny unrestricted ingress on relevant ports, as per the business requirements. Enforce minimum open ports where possible and configure all network boundaries to restrict all traffic unless explicit business requirements are mandated.
5. Limit exposure with policies to restrict cloud services: Define cloud service policies to limit the use of unused cloud services. It is recommended to define policies to avoid monitoring services being turned off and limit the regions in which cloud services can be consumed.
6. Enable Central Logging/Monitoring: Centralized security logging and monitoring are crucial to understand the current security posture and to identify security incidents. It is recommended to always enable the default logging capabilities, with a strategy for cloud security events. For audit and forensics, eventually, logs should flow into a central encrypted repository, with archiving policies in place. Have a robust security monitoring of all applications/environments and log as much data as possible, taking care not to log any sensitive data such as usernames and passwords. The log data can be very temporary, so they should be backed up periodically.
   
   Implement defined log retention period for API call logs and cloud platform service logs. Log all activity, including API calls, network traffic, administrator and root account activity, and tasks requiring high privileges (e.g., delete requests, Encrypt/Decrypt requests, etc.).
7. Automate Security: The low-hanging fruits such as cloud service misconfigurations could be automated. Notifications can be trigged via native services or functions also to identify misconfigurations. Its recommended to automate fixes wherever possible (to reduce manual fixes). If the remediation actions can be integrated with Service management tools, nothing better for governance. 
8. Implement “Defense in Depth”: Use native cloud services and third-party security solutions where possible to enforce layers of defense. Address security before workloads is deployed and implement controls to mandate the use of Web Application Firewall (WAF) or alternative mechanisms to protect applications from Internet-based cross-site forgery, cross-site-scripting (XSS), SQL injection attacks, etc.

Besides, the key must have discussed above, from an incident management standpoint – it is crucial to implement a process to communicate with external stakeholders as part of incident management. Implement communication cadence with distinct groups, business units, and individual roles notified in the event of an incident and update definitions for Critical, High, Moderate, and Low vulnerability as per industry standards. For example, a CVSS score of 8.0 or higher for Critical vulnerabilities.

Improve your Cloud Security Posture – Talk to Our Delivery Head