Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Applied Security for Containers, OW2con'18, June 7-8, 2018, Paris

•
•
OW2
OW2

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 of 21
Download to read offline
1 Applied Security For Containers Jesus ESCOLAR CEO EXELERYS NextGen CyberSecurity & CyberIntelligence
2 Infrastructure “Changes” Physical Virtual Cloud Containers Serverless 1011010 0100111 0010011
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 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 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 Logic behind Containers
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 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 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 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 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 Security Solutions for Containers – Vulnerabilities • NeuVector Open Source CIS Kubernetes Benchmark https://github.com/neuvector/kubernetes-cis-benchmark
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 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 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 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 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 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 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
21 THANK YOU! Follow us at: @EXELERYS LINKEDIN.COM/COMPANY/EXELERYS

More Related Content

Applied Security for Containers, OW2con'18, June 7-8, 2018, Paris

  • 1. 1 Applied Security For Containers Jesus ESCOLAR CEO EXELERYS NextGen CyberSecurity & CyberIntelligence
  • 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.
  • 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