Migrating to the cloud is no longer a forward looking trend: it’s the industry mainstream, with about 70 % of production applications running in the cloud. Clearly, cloud security is becoming synonymous with cybersecurity.
Radware’s senior product marketing manager, Eyal Arazi, cautions that organisations need to protect their cloud applications while considering the special characteristics of public cloud environments and the security challenges that they pose.
He says that although most production applications now run in cloud environments, many organisations still use on-prem deployments. Usually this is for testing, and once the application is released to production, it heads for the cloud.
Moving to the cloud is all about agility and speed. But frequently this comes at the expense of security, leaving organisations, customers, and their data at risk. Adopting multi-cloud and hybrid cloud strategies, adds additional challenges and threat vectors to an increasingly complex environment.
Four common cloud vulnerabilities frequently lead to a breach:
It’s the oldest mistake in the book: spinning-up a new cloud resource but leaving it publicly accessible and completely unsecured. Hackers routinely employ automated tools to scan target networks for any exposed assets, meaning that unsecured public assets are virtually guaranteed to be discovered.
Cloud security is still a ‘greenfield’ for many security practitioners who are unsure exactly which cloud configurations they need to close down, and how. Misconfigurations come in many shapes and forms, but one constant is how ubiquitous they are. Almost any organisation, security practitioner and application can fall victim to some type of cloud security misconfiguration.
While moving to the cloud enables fast business operations, access credentials are frequently handed out in hasty and unnecessary manner, so many users end up with excessive permissions for which they have no business need. Should any of those credentials fall into the wrong hands, attackers will have far-reaching access to sensitive data.
According to IBM’s 2021 The Cost of Data Breach report, stolen credentials are the main cause of data breaches, accounting for one in five breaches. Attackers use stolen credentials for malicious purposes, accessing the network, searching for sensitive data, and then exfiltrating it and selling it on the dark web.
This is an even bigger problem in cloud environments, where security managers have less visibility and control over the actions of cloud users.
Attackers use automation, so should defenders. The 2019 Capital One data breach shows that even the largest and best trained organisations can fall victim to sophisticated cloud attacks. An intriguing detail here: the hacker who breached CapitalOne also attacked at least 30 other organisations.
How can a single hacker achieve such scale? With automation. Automated tools have become a common component of hackers’ toolkit. While many are labelled as ‘ethical hacking’ or ‘testing’ tools, they are frequently used by hackers to perform reconnaissance against potential targets.
Here are a few common tools used for reconnaissance and penetration of applications and cloud networks:
This list is a just a sample of dozens of other tools. Many are intended for use by infosec experts and security professionals, yet they are frequently used by hackers who leverage them to identify weaknesses in target networks and exploit them.
Cloud defence strategies: What can organisations do against such an array of automated scanning, reconnaissance and exploitation tools? Leverage automation. Use of defensive automation procedures can prevent easily exploitable vulnerabilities and automate attack detection if, and when, an organisation is penetrated.
There are dozens of tools available for use by infosec experts and security professionals, yet these are frequently used by hackers who leverage them to identify weaknesses in target networks and exploit them.
Publicly exposed assets: Running in the public cloud makes it easy to spin up new resources and forget to secure them. Automated defensive tools can help to identify publicly exposed assets and ensure they are secured.
Cloud misconfigurations: Make sure the cloud environment does not fall prey to common cloud misconfigurations that make cloud networks vulnerable to penetration and exploitation.
Excessive permissions: Public cloud environments are notorious for granting unnecessary permissions to users who have no business need for them. Intelligent permission analysis methods and smart hardening procedures can help to crack down on excessive permissions, limiting the threat surface without interfering with business activities.
Compliance violations: Since cloud security is frequently a black box to many organisations, a primary objective for many migrating to the cloud is to make sure they comply with national and industry standards. Defensive automation can help to identify compliance requirements an organisation might not be meeting and address them.
Assume a breach: The threat vectors and attack surfaces that must be protected are nearly infinite, but beginning with the vectors listed above is a good place to start and will go far to ensuring that data is protected.
However, since the threat surface is so large, it is virtually impossible to guarantee that hackers won’t penetrate it. Assume that penetration is a matter of when, not if, and plan accordingly.
By using automation, there are a number of different steps to be taken immediately for when that fateful day comes:
Detecting suspicious activity in a cloud environment is potentially indicative of data breach activity. Using a risk-prioritised detection engine will enable CISOs to focus first on the alerts which matter the most.
Many detection tools can detect practically every peep on a network. However, this only leads to alert fatigue. What’s required is an engine that not only detects events, but also correlates them into unified storylines showing step-by-step progression of the attacks.
Detection is only half of the equation. And while many attacks take time to unfold, an organisation wants to respond fast. So, an automated response is critical to stopping attacks the moment they are detected and before any damage is done.
Cloud native protection
Leading vendors offer cloud native protector tools to help organisations lock down their cloud security posture and protect against common vulnerabilities to their public cloud environments. Other posture management apps enable security managers to quickly identify security vulnerabilities to their cloud security posture, isolate them and close them off.
It will pay to access other key security tools capable of delivering:
- Cross-cloud, cross-account visibility and reporting across all cloud accounts on AWS and Azure.
- One-click compliance reporting across a wide variety of industry standards, including PCI DSS, HIPAA, CIS Security Foundations, NIST, SOC2 and more, with detailed visual compliance reports and granular details on compliance errors.
- Custom governance enforcement based on user-defined conditions, using a query language for meeting organisational-specific governance rules.
- Automatic detection of cloud inventory and public exposed assets.
- Detection of cloud misconfigurations across a wide array of categories, including identity and access management, authentication, logging, encryption, and more.
- Automatic response options, using a visual wizard to easily define remediation rules for specific events and triggers and guarantee vulnerabilities are mitigated as soon as they are detected
Also seek advanced capabilities for cloud infrastructure entitlement management (CIEM) to remediate excessive permissions and other IAM vulnerabilities. Sophisticated cloud threat detection and response (CTDR) tools are also important for immediate detection, correlation, and response of malicious activity within the cloud environment.
Together, these features provide comprehensive, multi-layered security for public cloud environments, helping organisations to secure their workloads and ensure their customer data is not exposed.