Friday, December 18, 2020
By Charles Buege and Maril Vernon, Fuel User Group Members, Fuel Editorial Advisory Committee
View part one, part two and part three.
Ever been in the incident meeting where someone asks, “How did this happen?” And the IT department responds, “Well, it was the cloud provider’s responsibility,” and then the vendor on the phone counters with, “No, it is very clearly the customer’s responsibility.” Once you start pulling in different cloud providers, there are many misconceptions with regards to who is responsible for handling what tasks. Many times, it is assumed the cloud service provider (CSP) is taking care of something, and to the mental back-burner it goes. However, this assumption leaves you open to attack, compromise and theft of IP; otherwise known as “resume building events.”
In part four of our “Cloud Myths You’re Probably Falling for Right Now” series, we’ll go over some of the most common misconceptions that people have regarding the shared responsibility model that the cloud is built on; and controlling access into your cloud resources.
Myth #1: Cloud security is the responsibility of the cloud service provider.
No. The cloud provider is not responsible for securing your, the customer’s, resources. The immediate response that a lot of customers say to this is, “Well, why would I want to put it into the cloud then if they don’t secure the systems?” Yes, the cloud provider does secure the systems that you will be using, but they are not responsible for securing the resources within their system that you are using. That is your responsibility.
The problem is that the cloud provider doesn’t have a way of knowing for sure when you set up a web server, for example, if you want port 443 opened or not. Sure, the cloud provider could have that opened by default, but do you, the customer, want that port automatically opened? Not necessarily. You may not have set up authentication on port 443 yet so may not be ready for that. You may not be running your web server on port 443 for whatever reason. Heck, your application may not even have a web server as part of the infrastructure. For that reason, how can a cloud provider be held accountable for handling the security for this? Therefore, this type of security is handed off to the customer and not done by the cloud provider.
As stated earlier, when it comes to accessing the administration portal and the servers and systems that the cloud provider itself runs upon, the cloud provider is responsible for that security. For this reason, the term “cloud security” in the myth’s initial statement does need some clarification. With regards to this myth, when the term “cloud security” is being used, it is usually in reference to the company’s application/site/usage.
Myth #2: Moving to the cloud, my provider will take care of everything for me. I don’t need to do any administration anymore.
This is another misconception that a lot of people don’t realize. First off, this is not a simple yes/no answer either because here is where the factor of “shared responsibility” does come into play. If you are writing your own application/system and have complete control over the system, then the control and administration is completely on you. On the other hand, if you are heading down the route of utilizing either an IaaS, PaaS or a SaaS solution for a cloud provider, then you split up a lot further who handles what with regards to the access control.
Myth #3: Private cloud is more secure than public cloud.
First off, let’s clarify the definitions of private cloud and public cloud. Public cloud is a cloud computing deployment that is controlled by a third party being used by a customer. Private cloud is a collection of cloud computing resources that are being used by a single business or organization where the resources that are being used are either owned by a third party or an organization’s on-site datacenter. The common misconceptions of this myth is twofold when it comes to private cloud: 1) that most people think that a private cloud is the same as a public cloud but doesn’t have anything to do with your on-site datacenter and 2) is only accessible by your company.
So, in answer to the myth, if your security is done properly yes, your private cloud should be more secure than your public cloud. That is correct. The only issue you could run into, though, is that if you don’t follow your security processes in your private cloud as thoroughly as you do on your internal network then you’re still going to be as insecure in your public cloud. If, on the other hand, and this is where the myth comes into play, you are depending on your cloud provider to inherently have some default security in place to protect you, you may be presuming you have protections in place that aren’t actually there.
Our recommendation is that you always assume that you do not have any inherent security and need to put those safeguards in yourself. There have been too many times that we have assumed that there is going to be “something there” to protect us and with that experience, we’ve found that it is better to just plan on putting the security into place ourselves.
Myth #4: You should just give someone whatever access they are asking for.
We cannot disagree with this myth more. No, no, no! There is no reason to give a user more access to a system than they need. Why is this?
There is a mentality out there that goes by a couple of different names, but the most common name we’ve seen is the “principle of least privilege (PoLP).” The principle of least privilege is intended to give the user, program, system, process, etc., only the level of access that is necessary to perform a given task. For example, if an application is going to run on a server to perform backups, then the application won’t need the rights to install programs, will it?
Least privilege is an industry standard that should be followed in all cases when granting access.
Since we do live in the real world and we can’t always work in absolutes, we can think of at least one instance of when granting full access to a system isn’t as much of a “big deal” — working in a development environment. Granting a developer full access to a system makes sense, but even then, there needs to be consideration taken here as well. Do you want to grant full access to a developer on their first day at a company? Always think before granting access.
If you found these myths helpful or interesting and would like more information, please contact the Fuel Editor at editor@fuelusergroup.org.
Maril Vernon, aka “@SheWhoHacks,” is a penetration tester and PluralSight author with courses published on Red Team tools and MITRE-driven testing methods. Since entering cybersecurity in 2018, Maril achieved seven certifications in pentesting and security, accelerating her career in unprecedented time. Recently, Maril was also a contributing editor of the latest CIS AWS Foundation Benchmark for cloud security.
Charles Buege is the senior DevOps engineer for Temeda, an Industrial IoT company out of Naperville, Illinois. He currently holds a PCNSA certification and is working towards his PCNSE. He also runs an IT-based Meetup group called “The IT Crowd”.
More to Explore
Check out these Fuel blog posts for further reading: