Recently, I had the opportunity to interview the development team at Aqua Security. Our discussion focused on the role their solution fills in the Information Technology space. The team at Aqua Security most recently spoke at the BlackHat conference, which will be addressed in a follow-up article, to be published in the next week or two. After hearing about their solution, I felt like the first interview should be focused on the Aqua Container Security Platform.
My interview focused on Michael Cherny, who is the Head of Research at Aqua Security and is based out of their Tel Aviv, Israel location. Michael brings over 20 years of cybersecurity experience to Aqua Security - featuring past employment engagements at Microsoft, Aorato and Imperva. His expertise is often shared through presentations at BlackHat, RSA (Europe) and Virus Bulletin.
John Vester: Thank you for taking time to speak with DZone, Michael. For those unfamiliar with Aqua Security, can you provide a summary of the need Aqua Container Security Platform fulfills?
Michael Cherny: Of course. We secure applications built using software containers through our Aqua Container Security Platform. Our platform has the ability to secure containerized applications that run on-premises or in the cloud - running on either Windows or Linux - and supporting multiple orchestration environments (Amazon ECS, Docker Swarm, Redhat OpenShift, Kubernetes, Mesos Mesosphere).
How Aqua Security Fits Into Your Container Strategy.
What is your approach for providing security?
We look at the whole picture, building upon the CI/CD pipeline. On the left is where your developers are working on a daily basis. On the right, is where your containers are published and running in production.
On the developer side (the left side), we provide vulnerability and liability security/scanning so that we can scan for sensitive data - SSL, SSH private keys, AWS tokens, etc. - making it easier to adhere to your corporation's security policy. Our solution will alert the developer to warn them that sensitive data has been found, prior to the image being published and minimizing the impact of such an infraction being deployed.
As an example, earlier this year someone at IBM's Data Science Experience service mistakenly left the private keys to connect to their Docker daemon in the actual container. Had our solution been running, we would have caught the presence of the keys, providing notification ahead of time.
What CI/CD tools do you currently support?
Currently, we support Bamboo, Jenkins, GitLab, GoCD, TeamCity and (Microsoft) VSTS natively through plug-ins, and other CI tools using our CLI scanner.
How does Aqua Container Security Platform find the vulnerabilities?
MC: We look at the data when we scan the contents of the image. The vulnerabilities we scan for have a particular structure, which our tool has been designed to identify and report. Additionally, we have a layer to provide user access controls - facilitating the ability to determine who can do what in your organization.
Is the focus of your solution focused on private container repositories or would your solution work on a public solution, like DockerHub?
We are designed to work with any cloud-based solution. If for some reason, your company pushes images to public repositories, we can scan those images as well. Where your container is published does not make a difference to us. Where our product adds value in that case, is that we can catch vulnerabilities and liabilities, that if published, could lead to an embarrassing situation - similar to the example with IBM's Data Science Experience service noted above.
Let's talk about the right-side of the CI/CD picture.
Sure. Assuming your image passed testing in development and conforms to policy, we would let it run as a container in your environment. But we don't stop there, since even vulnerability-free containers may be abused through zero days, user errors or privileged users. We look at the container behavior using machine learning, and whitelist good behavior, alerting on or preventing everything else. For example, each container has network connections, files it uses, executables it runs etc., that have legitimate functions in the application. But everything else we can block.
So, if I have a script that is inside a Docker container, but is only supposed to run in non-Production environments, the Aqua Container Security Platform solution will restrict that script from actually running?
Sort of. We look at your production environment. We learn from the Docker file and determine the standard behavior. From there, we have an understanding of what is expected and then restrict anything else from being executed. In your example, if a particular script is not normally executed, we will not allow it to execute. Also, we allow the ability to add manual rules that specify elements that can or cannot be launched for a given image.
As a DevOps engineer, is there an application or user-interface that is utilized to setup and configure Aqua Container Security Platform?
Yes, our product includes Enforcers, which are containers deployed alongside your other containers on your nodes. Our Command Center provide a management console from which you configure your deployment and integrations, set policies, and monitor the containerized applications.
What happens when someone in run-time introduces something that is considered a risk or a vulnerability?
The course of action is dependent on how Aqua platform policies are configured. We have the ability to simply alert on the risk or vulnerability, to block the vulnerability, or block the specific activity. The Aqua platform also integrates with many other SIEM and analytics tools, so that security admins can get a full view of their container environment within their existing tools.
What impact does Aqua Container Security Platform have on the workload for those involved with the entire CI/CD pipeline? In other words, as a developer how is my daily life of providing features to the business change?
From the developer perspective, nothing really changes - security testing will be automatically performed as part of the build process, and if the code that the developer committed is in violation of policy, the build will fail and the developer will get a message or a ticket in Jira that tells them why it failed and what they need to fix. This is a much better process, in terms of security, quality and efficiency, than letting bad code ship, only to fix it later. We save that back and forth.
Is there a way to ignore a risk or vulnerability identified in Aqua Container Security Platform to allow the process to flow? As an example, the corporation may recognize the issue, but the fix may take time to resolve. In the meantime, builds and additional scanning needs to continue - skipping the noted concern for now.
With our acknowledge feature, this type of known risk or vulnerability can be silenced until ready to be addressed. Our goal is to handle the security posture, so that teams can focus on meeting the needs of the business lines they support.
Thank you for your time. Looking forward to hearing about your recent talk about BlackHat.
If your corporation has an application container strategy, taking some time to look at the Aqua Container Security Platform is something I highly recommend, regardless of where your containers are being deployed.
In my next article, the team at Aqua Security will talk about their recent presentation at the BlackHat US conference.
Have a really great day!