There’s a constant rise of the container usage in the existing cloud ecosystem. Most companies are evaluating how to migrate to newer, flexible and automated platform for content and application delivery. The containers are building themselves alone across the business, but who's securing them? This presentation discusses the evolution of infrastructure solutions from servers to containers, how can they be secured. What opensource security options are available today? Where is the future leading towards container security? What will come after containers?

1. 1
Applied Security
For Containers
Jesus ESCOLAR
CEO
EXELERYS
NextGen CyberSecurity & CyberIntelligence

2. 2
Infrastructure “Changes”
Physical Virtual
Cloud
Containers
Serverless
1011010
0100111
0010011

3. 3
The history of “Containers” – Everything started in…
• 1970’s!!!
• Unix V7: chroot! All was about process isolation at that time!
• 2000:
• FreeBSD: “Jails” was invented to share resources in a shared
environment independently.
• 2001:
• Linux-VServer: Introduced the FreeBSD “Jails” logic into the
Linux world through the “VPS” concept.
• 2004:
• Sun Microsystems: They invented the “Zones” long before
being acquired by Oracle. Their isolation logic allowed a
better implementation of Disk, RAM & CPU access.

4. 4
The history of “Containers” – Continued in…
• 2005:
• OpenVZ: Now we have the first “open-to-public” pre-
Dark Ages isolation implementation. <- We ‘ed it!
• 2006:
• Google: Introduced “Process Containers” as an isolation
logical model for CPU, memory, Disk I/O & Network.
• 2008:
• LXC: Halleluiah! A team of private companies along with
individuals developed the “Linux Containers”, the first real
implementation of a the container technology in an open-
source model with all the fully features that makes a
container what a container had to be! (LXC would evolve
to become LXD in its 2.0 version…)

5. 5
The history of “Containers” – And concluded…
• 2011:
• CloudFoundry: Implemented an evolved version of LXC
called “Warden” isolating environments in any OS with a
daemon and… an API!
• 2013:
• LMCTFY: An open-source implementation of Google
Container Stack. Now applications can be made “container
aware”. This moved to the Open Container Foundation in
2015.
• 2013:
• Docker: Here is the Saint Grail! It developed from LXC but
ended up having its own platform and architecture. The
successes were: API, container management platform, and
obviously, the apps ecosystem.

6. 6
Logic behind Containers

7. 7
Security Landscape = Customer Pain!
Evolving Infrastructure
Threat Sophistication
Speed of App Changes
Lack of resources, need to
simplify
Threat protection & audit
Performance across hybrid clouds
Customer PainTechnical Dynamics

8. 8
Security Landscape = Shared Responsibility
Data Encryption Network Traffic Protection
Platform, Applications
Operating System, Network & Firewall Configuration
Content and Applications
Foundation Services
Compute Storage Database Networking
Global
Infrastructure
Regions
Domains, Availability Zones
Foundation Services
Compute Storage Database Networking
Global
Infrastructure
Regions
Domains, Availability Zones
Cloud
Provider
or You?
Consumer !
The Shared Responsibility Model

9. 9
Securing Containers – What?
• So the magical question comes into play: What do I need
to secure when I am running containers?
• The Host?
• The Apps?
• The Images?
• The permissions?
• The users?
• The consumers?
• All of them?
• None of them?
Note: Choose all the right answers that apply…

10. 10
Security Paradigm for Containers
• Containers are running on top of an existing OS, whether we like it or not.
• Containers are still running either an OS or either apps.
• Containers are still running workloads with libraries.
• And those libraries are shared across all the containers in the same host.
• We still have all the security responsibilities from the traditional virtualization
landscape into our hands:
• Multi-tenancy / Multi-User responsibilities.
• App Packaging sources.
• Vulnerabilities / Patching.
• Accountability.
• Accessibility.
• Firewalling / Traffic management.
• RBAC.
• etc, etc, etc…

11. 11
Securing Containers – How?
• Resource Control: cgroups
• Discretionary Access: namespaces
• Mandatory Access: AppArmor / SELinux
• Fine Grained Access: seccomp
Is that all…? Nothing else? SecDevOps? DevSecOps?
No! There are few NextGen solutions with more in-depth
approach to cover all possible conditions.
Let’s see them together!

12. 12
Security Solutions for Containers – Vulnerabilities
• NeuVector Open Source CIS Kubernetes Benchmark
https://github.com/neuvector/kubernetes-cis-benchmark

13. 13
Security Solutions for Containers – Vulnerabilities
• Aquasec Open Source Tools:
https://github.com/aquasecurity/kube-bench
Automates the CIS Benchmark for Kubernetes, making it easy for
operators to check whether each node in their Kubernetes cluster
is configured according to security best practices.

14. 14
Security Solutions for Containers – Vulnerabilities
• CoreOS Open Source Clair:
https://github.com/coreos/clair/
https://coreos.com/clair/docs/latest/
Clair is an open source project for the static analysis of
vulnerabilities in appc and docker containers.
Since Clair image analysis is static, containers never need to be
actually executed, so you can detect a security threat before is
already running in your systems. Clair is the security engine that
CoreOS Quay registry uses internally.

15. 15
Security Solutions for Containers – Vulnerabilities
• Twistlock Developer Edition Container Security :
https://www.twistlock.com/products/enterprise-container-security/
https://www.twistlock.com/2016/02/17/free-developer-edition-is-
here/
Vulnerability management: Scanning container images to
discover vulnerabilities that may exist in the various layers of the
image.
Access control: Fine-grained access control capabilities to guard
access to Docker commands.
Runtime defence: Policy-based protection for running containers
on production servers.

16. 16
Security Solutions for Containers – Analysis
• Anchore Open Source Container Analysis
https://anchore.com/opensource/
• Pre-production analysis, vulnerability newsfeed.
• Submit an Image to be analysed
• See if your images have any known CVE vulnerabilities
• List all of the files in a particular image
• Evaluate your image against your custom security policy
• Subscribe to receive notifications when an image is updated

17. 17
Security Solutions for Containers – Behaviour
• Sysdig Open Source Falco :
https://sysdig.com/opensource/falco/
Open source, behavioural monitoring software designed to detect
anomalous activity based on the Sysdig monitoring technology.
Sysdig Falco also works as a intrusion detection system on any
Linux host.
Build rules specific to your Kubernetes clusters to enforce policy
across all your containers & microservices.
Complete container visibility through a single daemon. Easily build
rules and get informed immediately.

18. 18
Security Solutions for Containers – Distribution
• Notary Open Source :
https://github.com/theupdateframework/notary
Image forgery and tampering is one major security concern for Docker-
based deployments. Notary is a tool for publishing and managing
trusted collections of content. You can approve trusted published and
create signed collections, in a similar fashion to the software repository
management tools present in modern Linux systems, but for Docker
images.
Some of Notary goals include guaranteeing image freshness (most up to
date content, to avoid known vulnerabilities), trust delegation between
users or trusted distribution over untrusted mirrors or transport
channels.
Note: See this implementation of Notary.
https://theupdateframework.github.io/

19. 19
What’s next…?
• The future is unclear…
• Hosts can be infected, images can be infected, apps can be vulnerated.
• Docker images, as an example, is vulnerable to malware infection as
demonstrated in last Black Hat Conference in 2017.
• There’s a need for a full open source security solution for containers based on
a next generation security logic:
• AM + IPS + WR (mandatory)
• Behaviour Monitoring (necessary)
• ML + AI (optional)
• Sandboxing (highly desired)
• There are no open source NextGen Anti-Malware, Firewalls or IPS/IDS tools
for containers today.
• Why? The container ecosystem is too sparse, the CNF presents dozens of
vendors/companies building solutions and standards for containers, there’s
no homogeneity. There’s no alignment across the ecosystem. There’s no
standard practice.

20. 20
20

21. 21
THANK YOU!
Follow us at:
@EXELERYS
LINKEDIN.COM/COMPANY/EXELERYS