Securing Innovation in the Public Cloud
November 14, 2018
Director of Research, Lacework Labs
I recently attended the Colorado CSA Fall Summit and wanted to share some insights and themes from the conference. The CSA summit included presentations on all things cloud security. On the technical side, there were talks on DevSecOps, cloud pen testing, AWS encryption, cryptocurrency, and container security. One of the most prevalent themes of the conference was that the public cloud has enabled software developers to innovate much faster than ever before, but this environment operates quite a bit differently than traditional datacenters with relatively established security models. “Speed and scale” generally beats out “secure and safe,” so security needs to find a way to enable this innovation safely in a hostile environment, without slowing it down.
Shifting Security Left
Traditional security models for data centers focus on controls at the end of a pipeline, such as firewalls and pen-testing. Previous software development models, like a waterfall, used to have a place for security earlier in the process. With this development model becoming outdated and pace of development accelerating, it leaves little time for manual security review prior to every deploy.
A major theme at the conference was “Shifting Security Left” or adding security earlier in the process. This is not to stay we should throw out security at the end of the process, but we must acknowledge that many of these practices may not fit into the current deployment model. For example, a traditional firewall protecting your cloud applications isn’t feasible.
With agile and continuous deployment, security needs to find its place in a quickly iterating process, otherwise, it gets left behind. Below are a number of practices to achieve this.
- Security on the far left should start with training, such as developing safer code.
- Security should be present in the developer IDEs or in the form of automated ways of testing for common security issues during development.
- Automated (and it needs to be automated or it can’t keep up) security checks should occur at each major part of the deployment cycle. From build, test, deploy, and production.
- Treat a href=”https://www.lacework.com/solutions/infrastructure-as-code/” rel=”noopener” target=”_blank”>infrastructure as code and servers as immutable to reduce risks associated with the manual intervention of servers.
Along the lines of incorporating security strategies early in the development process another recurring topic emerged, container security. By container security, we mean everything from securing the infrastructure and network that containers operate on, the host, the container itself, and the container orchestration system.
Containers have given operators the ability to scale applications faster and more efficiently than ever before. As was the theme of the conference, this speed and efficiency mean new security challenges. Luckily many in this space are aware of these challenges and strive hard to develop best practices to reduce the attack surface. Many of these include:
- Restrict infrastructure network access as much as possible.
- Minimize attack surfaces on hosts by only deploying core functionality needed for your applications (e.g. CoreOS).
- Enable host security features when viable such as access control, system call restriction, resource restrictions, and mounting read-only devices.
- Develop a strong orchestrator security policy (e.g. not running privileged containers).
- Use role based access controls for containers.
- Reduce attack surface in application code by only using code that is needed.
- Pull images only from trusted resources.
Thoughts on Cryptocurrency
Lastly a few thoughts on cryptocurrency. Mining and trading cryptocurrency is very popular but also riddled with scams and malicious intent. Currently, it isn’t economically viable to mine popular cryptocurrencies, so most methods of mining involving using other’s resources in an unwanted or malicious way. It is very popular to compromise workloads or accounts for the purpose of hijacking or adding resources to mine currency. In general detecting unauthorized mining is pretty simple however there are more and more techniques being used to circumvent typical detection, such as domain fronting (traffic appears to go to legitimate domain), tunneling of mining traffic so its difficult to inspect, and intelligent ways of not using too many resources to set off alarm bells. The public cloud will continue to be a large target for this type of activity.
As a security practitioner, this is a very exciting and challenging time to be involved in this space. There are a lot of unknowns and a very large attack surface. Many organizations are in the middle of a transition to a faster pace in a new environment. With an optimistic attitude and a bit of curiosity, defenders will be able to develop new and innovative ways to protect the innovation occurring in the public cloud.