In the not too distant future, the majority of new enterprise software deployments will be cloud-native, forever altering the information security team’s core responsibilities. Picture a massive iceberg with only the tip visible above the surface of the water. Your cloud provider is responsible for the bulk beneath the surface – the infrastructure, networking, access control, etc. You are responsible for the tip – the application workload.
Google the term “AWS shared responsibility model” and you’ll find Amazon’s AWS Shared Responsibility Model that, while specific to AWS, likely mirrors the security relationship you will have with any cloud provider.
Amazon oversees the protection of the entire infrastructure that runs all of the services offered in the AWS Cloud, which comprises the hardware, software, networking, and facilities it uses to run AWS Cloud services. Over time, what AWS handles will increase and what you have to worry about will decrease. Whenever Amazon creates another service that shifts more of the infrastructure to their end and reduces operational load on the customer end, security moves with it.
Cloud providers are not running managed services, but they do provide infrastructure and network security. You’re guaranteed that your data will not be seen by other customers and that your applications are isolated from other users’ applications. What they stop short of protecting is anything that touches your application layer.
This makes your top priority ensuring the application layer is free of vulnerabilities. If you own the OS, you need to harden it, and using containers can make that more challenging because they often contain an OS as a base image. Even if you’re running on AWS and your instances are using a standardized OS template, you may still be running containers with Linux embedded in them. If they’re vulnerable, then so too are your applications.
You still oversee the network segmentation, the monitoring, the access control because Amazon can’t do that for you. Amazon doesn’t know who your users are, what your policies are, and what each application does. Amazon provides you the machines you need to run your stuff on, and they’re not going to let someone who’s not with your company see what’s on those machines or expose you to malware.
As you move more containers into production, you’ll discover that running containers on virtual machines requires only a minimal or “Thin OS”, which makes securing the operating system on the host level easier. You no longer need to leverage many of the other capabilities that enterprise-grade Linux provides, such as RHEL. Instead, you’ll use a thin OS like CoreOS, Photon or Rancher OS that is just there to support running containers.
You’re not running mixed loads of containerized and non-containerized applications on same server. This in turn creates a smaller cyberattack surface. Unlike when you’re running a full server that requires overseeing a wide range of capabilities such as memory management, the container runtime engine handles that. From a host perspective you’re really running one main process – the container engine. The rest is run by the containers themselves.
As you migrate to thin OS hosts, the endpoint security tools you use to secure “normal” hosts now become overkill because you only have the orchestrator accessing the host and running the containers. That likely means you’ll be using Kubernetes to manage the hosts without much manual intervention, such as an admin logging in to apply patches. In fact, attempting to make any manual changes to the configuration will trigger an alert.
As you continue to migrate more software deployments to the cloud, you can take the next step by making the thin host to no-host transition. The term “no-host” is misleading, there is still a host of course, but you never have to manage or configure it.
That applies both to serverless/Function as a Service (FaaS) and to on-demand container offerings like Fargate. All you’re doing is saying, “I want to run this function or this container for X amount of time.” You’re not deploying or managing any machines, everything is done for you. You only care about the workload. Just as with the thin OS host model, your top priority is preventing vulnerabilities and controlling behaviors in a way that prevent those functions or containers from coming back to bite you.
Theoretically it is possible for someone to infiltrate a function or container, and then use the output they have with the rest of your application to send malicious code or access/steal some data. Preventing that from happening requires you to set behavioral limits.
For example, you may set a function that you only use to send it data, have it perform some processing and return data to you. This creates two things to guard against. First, you don’t want the function to get data it isn’t supposed to receive. That’s easy to prevent by enabling it to only push data, not pull. On the push side, sanitize the inputs via common methods by not allowing specific characters (i.e., apostrophes or colons) or using bind variables where the database doesn’t accept a query without a certain set of variables that are within bound parameters. Second, make sure to sanitize the output to ensure it does not include malware or SQL injections.
So, as you make the transition from on-prem to a thin host, and eventually to a no-host model, there’s a simple progression to follow. First, don’t run mixed workloads. Second, if you’re running containers on a host, use a thin OS or a minimal OS and be sure to harden it. Implement security controls, and the good news here is that those controls will be minimal compared to what you’re likely still running to protect all of your endpoints. Instead, all you will have to do is secure the workloads themselves.
Eventually your concerns over host-based security will all but disappear, and you can focus on securing workloads at the application layer. You’ll relieve your team of all infrastructure and network security responsibilities as that work transitions to the security professionals at your cloud provider partners like Amazon, Google and Microsoft.
This blog is provided for informational purposes only and may require additional research and substantiation by the end user. In addition, the information is provided “as is” without any warranty or condition of any kind, either express or implied. Use of this information is at the end user’s own risk. CenturyLink does not warrant that the information will meet the end user’s requirements or that the implementation or usage of this information will result in the desired outcome of the end user.