How to rethink risks with new cloud deployments

These days, technology seems to evolve at the speed of light. Infrastructures change, attack surfaces reduce and multiply and, not surprisingly, your cloud environment advances. However, with new cloud deployment scenarios created to accelerate business operations, the risks also change. While many times the risks are not new, they are redesigned to infiltrate modern architectures.

Threats facing cloud deployments

This article will uncover the top threats facing modern cloud deployments and provide strategies to help organizations stay ahead and prevent threats.

Lateral attacks

This sophisticated attack type was in the news quite a lot in 2020 with the Sunburst Attack. It involves the ability to move laterally undetected in the cloud. Doing so successfully requires knowledge of many techniques, as the attacker moves deeper into the network to gain sensitive data and high-value assets.

Often with lateral attacks, the attacker first gains access to key pairs and sets up a temporary credential using specific commands. They then gain low-privilege access into the account. They may also try a brute force attack to obtain permissions. They then conduct lookup events to see what activities they can emulate and then move laterally to execute those same commands as they move throughout the system to escalate their function privileges and role. They repeat this until they have sufficient permissions to exfiltrate databases and other information.

To offset the likelihood of success in this attack scenario, it is important to restrict the permissions of your roles and assets, only allowing actions that are necessary. This reduces the risk of an attacker being able to escalate their permissions. Also, create alerts to show anomalous behavior. While one alert may not cause an alarm, a series of similar alerts could allow you to take action faster and potentially use automation to prevent the attack from executing.

Injection attacks

Attacks such as SQL injection, OS command injection, and code injection remain as risks for organizations, whether in traditional or modern microservice environments. The challenge of blocking injection attacks is exacerbated by the complexity containers and serverless functions add to an environment.

The methodology of the attacks remains the same: an application processes in input from an untrusted source. However, with microservices, inputs are triggered through numerous events, and this is challenging to manage manually. This means that we must not rely solely on security controls and the monolithic application layer, but rather on ensuring the code is secure and not vulnerable to an injection attack.

With so many vulnerable code available publicly, attackers can easily leverage it to exploit the environment. For instance, by having access to the environment an attacker can manipulate function code using injection to carry out an attack. To offset the likelihood of this attack type, least privilege permissions are imperative for the code to make sure no one can perform or access more than required. It is also important to conduct automated code scanning to identify vulnerabilities in any code repositories or libraries you utilize.

Broken authentication

With microservices, you have hundreds of different functions running separately, each with their own unique purpose and triggered from different events. Each one of these functions requires its own unique authentication protocol, and that leaves room for error.

Attackers will look for things like a forgotten resource or redundant code, or open APIs with known security gaps to gain access to the environment. This will then allow the attacker to gain access to a website containing sensitive content or functions, without having to authenticate properly.

While the service provider will handle much of the password management and recovery workflows, it is up to the customers to make sure that the resources themselves are properly configured. However, things get more complicated when functionality is not triggered from an end-user request, but rather during the application flow, in such a way as to bypass the authentication schema.

To address this issue, it is important to have continuous monitoring of your application, including the application flow, so you can identify application triggers. From there, you will want to create and categorize alerts for when resources fail to include the appropriate permissions, have redundant permissions, or the triggered behavior is anomalous or non-compliant.

Security misconfiguration

In traditional applications, security misconfigurations can happen at any level: the network, web server, applications server, containers, etc. For cloud, the storage and databases are encrypted by default. However, to enhance security, the customers could provide their own encryption keys or create more separation in a multi-tenant architecture.

It is important to understand some of the nuances. How can unlinked triggers, unprotected files, and directories impact your security posture? A few examples may include an attacker trying to identify a misconfigured area so that they can gain access and cause denial of service, or to leak sensitive data.

To offset this, make sure to leverage built-in services from your cloud provider, as well as third-party services to scan your cloud accounts to identify public resources. Review these resources and verify that they have enforced access control and follow best practice guidelines. Create alerts and set up ways to continuously monitor the cloud environment, so if anomalous behavior is detected, or a misconfiguration identified, it can be quickly addressed. For microservices, look for unlinked triggers and resources that are not linked back to the function. Make sure to also set timeouts to the minimum required by the function and required concurrency and always follow configuration best practices.

Third-party vulnerabilities

This has been mentioned in a few of the previous attack and risk areas but deserves another independent call-out. With the growing execution of microservices, the developers have more control over cloud infrastructure, and therefore have more responsibility as it pertains to security.

The cloud is about agility and moving fast. Applications and functionality can be launched with a click of a button, which often means that code and APIs are being copied. If there are hidden vulnerabilities, broad permissions, or redundancy built into the code repositories, those can easily be incorporated into the cloud application environment.

However, it is not as easy as establishing a security gate or QA testing. That will only slow down development and take away from the cloud’s agility. This is where system integration and automation play a critical role. It is important for security teams to establish automated security measures early into CI/CD. They must ensure best practice standards and compliance measures are integrated into the resource prior to deployment.

The system should also make sure that the code is scanned prior to launch for vulnerabilities. Then during runtime, it is important to have continuous scanning of the runtime environment to quickly identify vulnerabilities and, whenever possible, auto-remediate issues.

Conclusion

According to 451 Research, 90 percent of all workloads are in the cloud today, and the ways in which the cloud infrastructure is deployed will continue to advance and expand.

It is important for security teams to understand how the threat landscape will evolve with the newly emerging deployment models and changing attack surfaces. It is equally important for them to further integrate with their cross functional teams to best optimize security tooling and procedures. This will ensure security does not stop development, and that development does not jeopardize security.