It may be Infrastructure as a Service but you still need to do the work…
Opinions expressed are solely my own and do not express the views or opinions of my employer
When I think of service, I think of raising a flag on my beachside palapa to signal I’m ready for another margarita and having it delivered moments later. When I think of great service, I don’t even have to ask, someone is already offering me another margarita. I really don’t need to do much.
As a security practitioner, when I think of Infrastructure as a Service, I think of something very different — something called the Shared Responsibility Model. Sadly I’m not quite smart enough to figure out what the margarita equivalent is… but I would love one right now — thanks.
Basically, the Shared Responsibility model describes how cloud service providers (CSPs)and consumers of these cloud-based services should share responsibilities when it comes to ensuring security in the cloud. As AWS states: “vendors are responsible for security of the cloud; companies are responsible for security in the cloud.”
More simply, the CSP owns and controls the cloud, and you own and control everything you do in it. This control allows CSPs to provide customers with the benefits of greater flexibility, scalability, and cost-efficiency through the scale benefits, consistent services and automation they can achieve by delivering a defined service in their own way without pandering to individual customer requests.
What the shared responsibility model for IaaS doesn’t mean for security
It doesn’t mean that the CSP provides security as a service.
IaaS means the CSP manages and controls the host operating system, the virtualization layer, the physical security of the facilities where it is all hosted and the management layer used to deliver this all to you as a service. This allows you to innovate, build, configure virtual infrastructure, guest operating systems and the applications you build on top of it. This also means all of the security you would normally configure to secure a server on premise needs to be considered from firewalls (or security groups in the cloud), access control, host protection to web application control. Some of these are provided as services by the CSPs, but typically you would need to procure these services in addition to your primary service.
It doesn’t mean that your access to the cloud service and management layer is secure
Access to the cloud is one of the most important things to secure when first setting up a cloud service. Multi-factor authentication is essential on any account used to access and manage the cloud. Why not invest in U2F tokens while at it.
It doesn’t mean that access to infrastructure created in the cloud is secure
Think about it. You accessed it via the internet. Unless you’ve configured it to restrict public internet access by default, it probably still is accessible via the internet. Similarly you’ll need to restrict access from within your account and other accounts, before even thinking about application layer protection through a Web Application Firewall.
It also doesn’t mean that you should only worry about securing the application only, as the infrastructure is already secure.
Remember all the steps you took when installing a new operating system (OS) on premise. You needed to put in a lot of effort to harden the OS, patch to latest versions, setup accounts and access controls, install the relevant security agents, configure network access and firewall rules. Some of this can be automated and prebuilt, but you still need to do it.
It doesn’t mean you have a Disaster recovery or backup strategy
The scale, sophistication and geographical spread of your CSP means they can offer you a lot of 9s in availability, but you have to remember this is not a Disaster recovery or backup strategy. It also isn’t a commitment that your data and systems will be available, but a service level on when the CSPs services will be available.
With this in mind, you must have a solution to manage your infrastructure within the cloud environment to schedule and perform backups, implement retention policies, and replicate cross-region and cross-account for additional layers of disaster recovery protection, including potentially multi-cloud.
What it does mean
It means you no longer have to deal with the physical burden of a Data centre
The CSP will operate, manage and control all the components from the host operating system and virtualization layer down to the physical security of the facilities. If you remember the hassle of procuring, racking, stacking, installing, configuring and protecting physical infrastructure, that’s a really massive operational burden that you no longer have to deal with.
It means that you also need to manage access to the Cloud and it’s management features
Infrastructure as a Service does mean that the CSPs provide the ability to manage just about everything in your account, but it means that there are some privileges that you haven’t had before. Imagine a big red button that says destroy all the computers in my data centre? Didn’t have that before did you? Well — You probably don’t want too many people to have access to it.
It means you have to think about infrastructure differently but not forget about it
When you consider the time and money you save by not having to deal with physical hardware and network concerns, being able to stand up new infrastructure in seconds anywhere in the world, why would you squander it by continuing to follow out-dated processes for security. The ultimate goal for cloud native infrastructure is for it to be distributed to avoid single points of failure, immutable to unauthorized change and ephemeral — only being stood up when it’s needed. As a result, your whole approach to security needs to change to fit into this paradigm of cloud native infrastructure.
It means getting back to basics with authentication, authorization and accounting at scale
If all your infrastructure is accessible via the internet and that infrastructure is constantly changing with access control (written in JSON syntax) being the only thing preventing someone from accessing sensitive information on a S3 bucket or EC2, I would personally want to ensure that authentication, authorization and auditing controls were up to the task of protecting my data at scale.
Wouldn’t you?
I hope you’ve enjoyed this series of posts focused on the various challenges of access control and privileges. Hopefully you found this of interest.
