According to Gartner, public cloud security refers to the processes, mechanisms and services used to control the security, compliance and other usage risks of cloud computing. While it includes security of the cloud service and security within the cloud service, it does not encompass security services delivered from the cloud (security as a service) that are intended to be used outside the cloud.
The current pandemic has accelerated the use of cloud services.
“The pandemic, and its resulting changes to the business world, accelerated digitalization of business processes, endpoint mobility and the expansion of cloud computing in most organizations, revealing legacy thinking and technologies,” said Peter Firstbrook, VP analyst, Gartner, during the virtual Gartner Security and Risk Management Summit, 2020.
Everybody has an opinion, an analysis, an interpretation of what constitutes cloud security, how it is achieved, what works and what doesn’t.
The following is shared by Check Point Software. Given that every security has developed what it likes to brag about as its unique value proposition and differentiation, care is advised in interpreting what the message is from the vendor.
1. The more security tools you have, the better
More security tools simply don’t equal more security.
The Oracle and KPMG Cloud Threat Report 2020 revealed that 70% of those surveyed report too many tools are needed to protect public cloud environments.
On average, each uses more than 100 discrete security controls. Multiple security vendors, providing disparate solutions, blocking on different attack vectors all results in gaps. And those gaps create access points for attackers:
• Too much cloud complexity
• Too many different security solutions
• Solutions not cooperating
• No shared intelligence or architecture, gaps, and risk
To overcome these gaps, it is imperative to implement tools and resources to help simplify the security management of the cloud and take control of security.
2. Security is the cloud provider’s responsibility
As a cloud customer, the end user organisation retains responsibility for securing the data they put in the cloud in the well-known, “shared responsibility model.” In securing cloud native infrastructure, it’s vital to understand exactly where the responsibilities lie, considering your responsibilities vary depending upon the services you’re consuming.
There are different ways to protect your data in the cloud, and organisations are failing to do majority of them.
3. Successful breaches result from sophisticated attacks
While it’s true that highly sophisticated attackers exist, the reality is that their growing sophistication is not the reason behind most successful attacks. Errors and misconfiguration on the part of the end users are what drive majority of attacks.
Gartner predicts that, through 2025, at least 99% of cloud failures will be the customer’s fault.
Movies may portray a Mission Impossible-style thrilling scene with attackers ducking under lasers and successful cracking the code to the vault door. But reality is more akin to a lucky thief simply encountering an unlocked door at the opportune moment – because the last person who closed the door failed to spin the dial.
Sergio Lourerio, cloud security director at Outpost24, said: “We are still in the early days of cloud infrastructure security and what we are seeing is a prevalence of opportunistic, not very sophisticated attacks, such as looking for publicly accessible AWS S3 data buckets.”
4. Cloud visibility is easy
You’re paying to use cloud resources, so you must know precisely what those resources are, as well as all the relevant info, such as:
- How many accounts do we have?
- Did the developers add machines, new functionality, or connect to the outside world?
- Who put that there?
- Is it configured properly?
- Does it have vulnerabilities?
- Can I stop them before it hits the runtime environment?
Unfortunately, all this info is much harder to keep track of than many realise. Without visibility into how resources should behave, you can’t observe when that behaviour deviates. Without consolidated dashboards, it’s very difficult to identify and act on threats in a timely manner.
5. Security is best left to security pros
As opposed to isolating security to the purview of dedicated security pros, best practices include making security everyone’s problem. For example, shift security left in the software development lifecycle, implementing security during development, rather than waiting for deployment, or worse, after deployment.
Make developers part of the process rather than taking an adversarial approach. Offer developers self-service functionality to assess security of a stack they’re about to deploy and provide tools to auto-remediate issues before they go into production.
6. The cloud is inherently more secure
This is a factoid: a bit of truth, and a bit of falsehood all wrapped together.
Truth Fuelling the Myth: Cloud providers are generally more reliable at tasks like patching servers. Leaving it up to them makes sense and trust in cloud service providers is deservedly high.
In, The Egregious 11, The Cloud Security Alliance (CSA) outlines the top threats to cloud computing. Recent survey responses showed a significant drop in the ranking of traditional cloud security issues under the responsibility of cloud service providers. Concerns dropped so low that CSA chose to exclude them from the latest report.
Cloud Security Concerns Busting the Myth: Securing everything across multiple clouds involves securing access, managing identities, and constant auditing, to name just a few. Increasing sprawl of workloads across multiple public and private clouds results in difficulty obtaining visibility and a lack of end to end context around risk. These challenges are only exacerbated by the security gaps inevitable with disparate solutions.
Serverless technologies fragment your app to smaller components that are callable. This shift, coupled with the use of event-based triggers from diverse sources (such as storage, message queues, and databases) means attackers have more targets and more attack vectors.
7. You must slow down developers to be secure
Taken from an article in Computer Business Review, “Developers should be empowered with plug-ins that trigger security and compliance controls at every step of the DevOps process, exposing the results right within the tools they commonly use to enable rapid remediation of the vulnerable code.”
Remediation steps must be automated whether to fix issues or streamline security processes. Enable developers to do their jobs securely, without adding work, like providing tools to automate tasks, such as generating permissions for server-less functions. Take steps to remove friction as opposed to slowing things down.
8. Security automation is ideal, rendering human oversight archaic and unnecessary
Again, a “factoid” here that mixes truth and fiction. The true security ideal is a combination of automation and human oversight.
The 2020 State of Pentesting report examined which web application security vulnerabilities can be found reliably using machines versus human expertise. “The study found that both humans and machines bring value when it comes to finding specific classes of vulnerabilities. Humans ‘win’ at finding business logic bypasses, race conditions, and chained exploits, according to the report.”
9. Security of SaaS apps is managed by the SaaS provider & requires none of your attention
Unlike IaaS, SaaS apps indeed don’t require your efforts to patch servers. As the end-user, you simply grant access to the employees of your organisation and let them run.
However, many SaaS apps will necessarily contain sensitive information. Users are often able to interact with files, including sharing and configuring access. And users granting access to others and not having that access rescinded when they leave your organisation are indeed security problems that require your attention.
10. S3 buckets are secure by default
As a default setting, Amazon S3 buckets are private and can only be accessed by those who’ve been granted access. So, yes, they are secure. However, much like seatbelts, they’re of no help if not used. And many data breaches result from misconfigurations such as merely making buckets public, or other errors like storing passwords in clear text in GitHub or S3 buckets.
According to Symantec’s 2019 Internet Threat Report, in 2018 “(AWS) S3 buckets emerged as an Achilles heel for organisations, with more than 70 million records stolen or leaked as a result of poor configuration.”
11. Containers and serverless functions are inherently more secure
Containers and serverless functions are designed to be ephemeral and tend to have short lifespans, which strengthens security. Attackers are unable to easily achieve long-term presence in your system.
While in essence, this statement is true, the use of event-based triggers from diverse sources means attackers have more targets and more attack vectors. Configured properly, these cloud native technologies absolutely can be more secure… but only if configured properly.
12. CVE’s are the only vulnerabilities i need to care about
As already stated, growing sophistication is not the reason for most successful attacks. Therefore, it’s logical to focus on mitigating the risk of the most common attack vectors.
However, deliberately choosing to neglect security outside the scope of CVEs will, by definition, lead to increased risk.
According to a report from Balbix, one of the 5 Kinds of Vulnerabilities that are NOT CVEs include misconfigurations, which, as stated, are the driver of many successful breaches.
As you can see, cloud security is riddled with myths, but once you unravel the myths, it is easy to uncover the facts and identify the strategies required to transform your business security into the cloud.
