As presented at OpenShift Commons Sept 8, 2016.
Cyber threats consistently rank as a high priority for data center operators and their reliability teams. As increasingly sophisticated attacks mount, the risk associated with a zero-day attack is significant. Traditional responses include perimeter monitoring and associated network defenses. Since those defenses are reactive to application issues attackers choose to exploit, it’s critical to have visibility into both what is in your container library, but also what the current state of vulnerability activity might be. Current vulnerability information for container images can readily be obtained by using the scan action on Atomic hosts in your OpenShift Container Platform.
In this session we’ll cover how an issue becomes a disclosed vulnerability, how to determine the risk associated with your container usage, and potential mitigation patterns you might choose to utilize to limit any potential scope of compromise.
Secure Application Development in the Age of Continuous DeliveryTim Mackey
As delivered at LinuxCon and ContainerCon in Berlin 2016.
Traditionally, when datacenter operators talk about application security, they've tended to focus on issues related to key management, firewalls and data access. By contrast, application developers have a security focus which is more aligned with code analysis and fuzzing techniques.
The reality is, secure application deployment principles extend from the infrastructure layer through the application and include how the application is deployed. With the prevalence of continuous deployment of micro-services, it’s imperative to focus efforts on what attackers’ view as vulnerable; particularly in an environment where new exploits are being disclosed almost daily.
In this session we’ll present:
• How known vulnerabilities can make their way into production deployments
• How deployment of vulnerable code can be minimized
• How to determine the vulnerability status of a container
• How to determine the risk associated with a specific package
Using hypervisor and container technology to increase datacenter security pos...Tim Mackey
As presented at LinuxCon/ContainerCon 2016:
Cyber threats consistently rank as a high priority for data center operators and their reliability teams. As increasingly sophisticated attacks mount, the risk associated with a zero-day attack is significant. Traditional responses include perimeter monitoring and anti-malware agents. Unfortunately, those techniques introduce performance and management challenges when used at large VM densities, and may not work well with containerized applications.
Fortunately, the Xen Project community has collaborated to create a solution which reduces the potential of success associated with rootkit attack vectors. When combined with recent advancements in processor capabilities, and secure development models for container deployment, it’s possible to both protect against and be proactively alerted to potential zero-day attacks. In this session, we’ll cover models to limit the scope of compromise should an attack be mounted against your infrastructure. Two attack vectors will be illustrated, and we’ll see how it’s possible to be proactively alerted to potential zero-day actions without requiring significant reconfiguration of your datacenter environment.
Technology elements explored include those from Black Duck, Bitdefender, Citrix, Intel and Guardicore.
Security in the age of open source - Myths and misperceptionsTim Mackey
As delivered at Interop ITX 2017.
The security of open source software is a function of the security of its components. For most applications, open source technologies are at their core, but security related issues may not be disclosed directly against the application because its use of the open-source component is hidden. In this talk, I explored how information flow benefits attackers, but how awareness can help defenders. I presented key attributes any vulnerability solution should have - including deep understanding of how open source development works and being DevOps aware.
As delivered by Tim Mackey, Senior Technical Evangelist - Black Duck Software, at LinuxCon and ContainerCon in Berlin 2016.
Traditionally, when datacenter operators talk about application security, they've tended to focus on issues related to key management, firewalls and data access. By contrast, application developers have a security focus which is more aligned with code analysis and fuzzing techniques.
The reality is, secure application deployment principles extend from the infrastructure layer through the application and include how the application is deployed. With the prevalence of continuous deployment of micro-services, it’s imperative to focus efforts on what attackers’ view as vulnerable; particularly in an environment where new exploits are being disclosed almost daily.
In this session we’ll present:
• How known vulnerabilities can make their way into production deployments
• How deployment of vulnerable code can be minimized
• How to determine the vulnerability status of a container
• How to determine the risk associated with a specific package
Open source reduces development costs, frees internal developers to work on higher-order tasks, and accelerates time to market. Quite simply, open source is the way applications are developed today. Mike Pittenger addresses security in the age of open source in this presentation.
Organizations of all sizes using automation and agile methodologies to improve the speed and reliability of their software development initiatives. In this session we will provide an overview and demonstrations of the various ways you can integrate Black Duck Hub with your CI/CD tools to manage open source risks throughout development.
Secure application deployment in the age of continuous deliveryTim Mackey
As presented at Open Source Open Standards (GovNet) (http://opensourceconference.co.uk/), this deck covers some of the material which operators of open source data centers and users of container and cloud technologies should be aware of when seeking to be security conscious.
Traditionally, when datacentre operators talk about application security, there has been a tendency to focus on issues related to key management, firewalls and data access. By contrast, application developers have a security focus which is more aligned with code analysis and fuzzing techniques. The reality is, secure application deployment principles extend from the infrastructure layer through the application and include how the application is deployed. With the prevalence of continuous deployment, it’s imperative to focus efforts on what attackers’ view as vulnerable; particularly in an environment where new exploits are being disclosed almost daily.
In this session we’ll present:
- How known vulnerabilities can make their way into production deployments
- How vulnerability impact is maximized
- A methodology for ensuring deployment of vulnerable code can be minimized
- A methodology to minimize the potential for vulnerable code to be redistributed
Secure Application Development in the Age of Continuous DeliveryTim Mackey
As delivered at LinuxCon and ContainerCon in Berlin 2016.
Traditionally, when datacenter operators talk about application security, they've tended to focus on issues related to key management, firewalls and data access. By contrast, application developers have a security focus which is more aligned with code analysis and fuzzing techniques.
The reality is, secure application deployment principles extend from the infrastructure layer through the application and include how the application is deployed. With the prevalence of continuous deployment of micro-services, it’s imperative to focus efforts on what attackers’ view as vulnerable; particularly in an environment where new exploits are being disclosed almost daily.
In this session we’ll present:
• How known vulnerabilities can make their way into production deployments
• How deployment of vulnerable code can be minimized
• How to determine the vulnerability status of a container
• How to determine the risk associated with a specific package
Using hypervisor and container technology to increase datacenter security pos...Tim Mackey
As presented at LinuxCon/ContainerCon 2016:
Cyber threats consistently rank as a high priority for data center operators and their reliability teams. As increasingly sophisticated attacks mount, the risk associated with a zero-day attack is significant. Traditional responses include perimeter monitoring and anti-malware agents. Unfortunately, those techniques introduce performance and management challenges when used at large VM densities, and may not work well with containerized applications.
Fortunately, the Xen Project community has collaborated to create a solution which reduces the potential of success associated with rootkit attack vectors. When combined with recent advancements in processor capabilities, and secure development models for container deployment, it’s possible to both protect against and be proactively alerted to potential zero-day attacks. In this session, we’ll cover models to limit the scope of compromise should an attack be mounted against your infrastructure. Two attack vectors will be illustrated, and we’ll see how it’s possible to be proactively alerted to potential zero-day actions without requiring significant reconfiguration of your datacenter environment.
Technology elements explored include those from Black Duck, Bitdefender, Citrix, Intel and Guardicore.
Security in the age of open source - Myths and misperceptionsTim Mackey
As delivered at Interop ITX 2017.
The security of open source software is a function of the security of its components. For most applications, open source technologies are at their core, but security related issues may not be disclosed directly against the application because its use of the open-source component is hidden. In this talk, I explored how information flow benefits attackers, but how awareness can help defenders. I presented key attributes any vulnerability solution should have - including deep understanding of how open source development works and being DevOps aware.
As delivered by Tim Mackey, Senior Technical Evangelist - Black Duck Software, at LinuxCon and ContainerCon in Berlin 2016.
Traditionally, when datacenter operators talk about application security, they've tended to focus on issues related to key management, firewalls and data access. By contrast, application developers have a security focus which is more aligned with code analysis and fuzzing techniques.
The reality is, secure application deployment principles extend from the infrastructure layer through the application and include how the application is deployed. With the prevalence of continuous deployment of micro-services, it’s imperative to focus efforts on what attackers’ view as vulnerable; particularly in an environment where new exploits are being disclosed almost daily.
In this session we’ll present:
• How known vulnerabilities can make their way into production deployments
• How deployment of vulnerable code can be minimized
• How to determine the vulnerability status of a container
• How to determine the risk associated with a specific package
Open source reduces development costs, frees internal developers to work on higher-order tasks, and accelerates time to market. Quite simply, open source is the way applications are developed today. Mike Pittenger addresses security in the age of open source in this presentation.
Organizations of all sizes using automation and agile methodologies to improve the speed and reliability of their software development initiatives. In this session we will provide an overview and demonstrations of the various ways you can integrate Black Duck Hub with your CI/CD tools to manage open source risks throughout development.
Secure application deployment in the age of continuous deliveryTim Mackey
As presented at Open Source Open Standards (GovNet) (http://opensourceconference.co.uk/), this deck covers some of the material which operators of open source data centers and users of container and cloud technologies should be aware of when seeking to be security conscious.
Traditionally, when datacentre operators talk about application security, there has been a tendency to focus on issues related to key management, firewalls and data access. By contrast, application developers have a security focus which is more aligned with code analysis and fuzzing techniques. The reality is, secure application deployment principles extend from the infrastructure layer through the application and include how the application is deployed. With the prevalence of continuous deployment, it’s imperative to focus efforts on what attackers’ view as vulnerable; particularly in an environment where new exploits are being disclosed almost daily.
In this session we’ll present:
- How known vulnerabilities can make their way into production deployments
- How vulnerability impact is maximized
- A methodology for ensuring deployment of vulnerable code can be minimized
- A methodology to minimize the potential for vulnerable code to be redistributed
Application security meetup - cloud security best practices 24062021lior mazor
"Cloud Security Best Practices" meetup, is about Secrets Management in the Cloud, Secure Cloud Architecture, Events Tracking in Microservices and How to Manage Secrets in K8S.
AWS live hack: Docker + Snyk Container on AWSEric Smalling
Slides from session 3 of the Snyk AWS live hack series
Dec 15, 2021 with Eric Smalling, Dev Advocate at Snyk, and Peter McKee, Head of Dev Relations & Community at Docker.
You need to establish clear operational and security processes around your app and container usage. Join this session to see how enterprise IT can use accelerate business agility, implement DevOps processes, and achieve greater security and control.
Secure application deployment in Apache CloudStackTim Mackey
At the Apache CloudStack Collaboration Conference in Montreal, I presented a potential pathway to secure template management in CloudStack. Under this model, cloud providers can assess the templates their users have and potentially advise if deployed instances have application security issues which have either public disclosures, or better still remediation.
This talk digs into the fundamentals of DevSecOps, exploring the key principles required to advance your security practices. Considering the changes in culture, methodologies, and tools, it will demonstrate how to accelerate your team journey's from endpoint security to built-in security and how to avoid the common mistakes faced when implementing your chosen DevSecOps strategy.
While vulnerability assessment tools can identify unpatched or misconfigured code bases, these tools overlook a large portion of an organization's attack surface: known vulnerabilities in applications that are built in-house.
Where does your organization stand with open source risk management? How are you identifying and securing open source used in your code? Measure your organization against these four levels to find out.
Why should developers care about container security?Eric Smalling
Slides from my talk at SF Bay Cloud Native Containers Meetup Feb 2022 and SnykLive Stranger Danger on April 27, 2022.
https://www.meetup.com/cloudnativecontainers/events/283721735/
Contain your risk: Deploy secure containers with trust and confidenceBlack Duck by Synopsys
Presented on September 22, 2016 by Brent Baude, Principle Software Engineer, Atomic and Docker Development, Red Hat; Randy Kilmon, VP, Engineering, Black Duck
Organizations are increasingly turning to container environments to meet the demand for faster, more agile software development. But a 2015 study conducted by Forrester Consulting on behalf of Red Hat revealed that 53% of IT operations and development decision makers at global enterprises reported container security concerns as a barrier to adoption.
The challenges of managing security risk increase in scope and complexity when hundreds or even thousands of different open source software components and licenses are part of your application code base. Since 2014, more than 6,000 new open source security vulnerabilities have been reported, making it essential to have good visibility into and control over the open source in use in order to understand if any known vulnerabilities are present.
In this webinar, experts from Red Hat and Black Duck will share the latest insights and recommendations for securing the open source in your containers, including protecting them from vulnerabilities like Heartbleed, Shellshock and Venom. You’ll learn:
• Why container environments present new application security challenges, including those posed by ever-increasing open source use.
• How to scan applications running in containers to identify open source in use and map known open source security vulnerabilities.
• Best practices and methodologies for deploying secure containers with trust and confidence.
"This workshop is for pentesters, security researchers or someone looking to get into IoT security but is reluctant due to the wide range of technologies involved and plethora of different tools. While it does require a considerable amount of knowledge in the domain, it is not as difficult as you may think. In this workshop we will introduce you to some of the important concepts and EXPLIoT framework in a very simple way that can be used for the various IoT attack vectors. The primary focus of this workshop is to introduce the attendees to the open source IoT Security Testing and Exploitation Framework - EXPLIoT (https://gitlab.com/expliot_framework/expliot) and enable them to use as well as extend it by writing plugins for new IoT based exploits and analysis test cases. It’s a flexible and extendable framework that would help the security community in writing quick IoT test cases and exploits. The objectives of the framework are:
1. Easy to use
2. Extendable
3. Support for hardware, radio and IoT protocol analysis
EXPLIoT currently supports the following protocols which can be utilized for writing new plugins/exploits:
1. Radio – BLE , Zigbee
2. Network – MQTT, CoAP, DICOM, MODBUS, MDNS, NMAP, TCP, UDP
3. Hardware – CAN, SPI, I2C, UART, JTAG
This talk would give attendees a first-hand view of the functionality, how to use it and how to write plugins to extend the framework."
Why cloud native envs deserve better security - Dima Stopel, Twistlock - Clou...Cloud Native Day Tel Aviv
Traditionally, security teams have been accustomed to investigating incidents and falling back to previous code releases if they detect serious issues. With the rise of modern cloud-native applications and immutable infrastructure, however, security engineers have new solutions at their fingertips. Immutable infrastructure refers to infrastructure with components that are designed to be destroyed and replaced with new versions whenever a change is necessary. This makes immutable infrastructure different from conventional deployment technologies, in which components were typically updated while they were still running rather than being redeployed whenever a change takes place. In this session, Dima Stopel will discuss the changing security landscape and how immutable infrastructure and cloud-native technologies such as containers, can make tedious, risk-prone security workflows a thing of the past.
Integrate Security into DevOps - SecDevOpsUlf Mattsson
1.Security Controls Must Be Programmable and Automated Wherever Possible
2.Implement a Simple Risk and Threat Model for All Applications
3.Scan Custom Code, Applications and APIs
4.Scan for OSS Issues in Development
5.Treat Scripts/Recipes/Templates/Layers as Sensitive Code
6.Measure System Integrity and Ensure Correct Configuration at Load
7.Use Whitelisting on Production Systems, Including Container-Based Implementations
8.Assume Compromise; Monitor Everything; Architect for Rapid Detection and Response
9.Lock Down Production Infrastructure and Services
10.Tokenization and Payment Processing
Monitoring Application Attack Surface to Integrate Security into DevOps Pipel...Denim Group
A web application’s attack surface is the combination of URLs it will respond to as well as the
inputs to those URLs that can change the behavior of the application. Understanding an
application’s attack surface is critical to being able to provide sufficient security test coverage,
and by watching an application’s attack surface change over time security and development
teams can help target and optimize testing activities. This presentation looks at methods of
calculating web application attack surface and tracking the evolution of attack surface over
time. In addition, it looks at metrics and thresholds that can be used to craft policies for
integrating different testing activities into Continuous Integration / Continuous Delivery (CI/CD)
pipelines for teams integrating security into their DevOps practices.
Presented by Tim Mackey, Senior Technology Evangelist, Black Duck Software on August 17.
To use containers safely, you need to be aware of potential security issues and the tools you need for securing container-based systems. Secure production use of containers requires an understanding of how attackers might seek to compromise the container, and what you should be aware of to minimize that potential risk.
Tim Mackey, Senior Technical Evangelist at Black Duck Software, provides guidance for developing container security policies and procedures around threats such as:
1. Network security
2. Access control
3. Tamper management and trust
4. Denial of service and SLAs
5. Vulnerabilities
Register today to learn about the biggest security challenges you face when deploying containers, and how you can effectively deal with those threats.
Watch the webinar on BrightTalk: http://bit.ly/2bpdswg
Securing Container Deployments from Build to Ship to Run - August 2017 - Ranc...Shannon Williams
Security should be integrated into every phase of the container application development life cycle, from build to ship to run. On August 31st, we hosted an online meetup to discuss the issues that need be addressed to achieve continuous security for containers.
The presentation included speakers from Rancher Labs (www.rancher.com), NeuVector (www.neuvector.com) and Black Duck Software (www.blackducksoftware.com) who discussed:
- Best practices for preparing your environment for secure deployment
- How to secure containers during run-time
- Actionable next steps to protect your applications
Applied Security for Containers, OW2con'18, June 7-8, 2018, ParisOW2
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?
Application security meetup - cloud security best practices 24062021lior mazor
"Cloud Security Best Practices" meetup, is about Secrets Management in the Cloud, Secure Cloud Architecture, Events Tracking in Microservices and How to Manage Secrets in K8S.
AWS live hack: Docker + Snyk Container on AWSEric Smalling
Slides from session 3 of the Snyk AWS live hack series
Dec 15, 2021 with Eric Smalling, Dev Advocate at Snyk, and Peter McKee, Head of Dev Relations & Community at Docker.
You need to establish clear operational and security processes around your app and container usage. Join this session to see how enterprise IT can use accelerate business agility, implement DevOps processes, and achieve greater security and control.
Secure application deployment in Apache CloudStackTim Mackey
At the Apache CloudStack Collaboration Conference in Montreal, I presented a potential pathway to secure template management in CloudStack. Under this model, cloud providers can assess the templates their users have and potentially advise if deployed instances have application security issues which have either public disclosures, or better still remediation.
This talk digs into the fundamentals of DevSecOps, exploring the key principles required to advance your security practices. Considering the changes in culture, methodologies, and tools, it will demonstrate how to accelerate your team journey's from endpoint security to built-in security and how to avoid the common mistakes faced when implementing your chosen DevSecOps strategy.
While vulnerability assessment tools can identify unpatched or misconfigured code bases, these tools overlook a large portion of an organization's attack surface: known vulnerabilities in applications that are built in-house.
Where does your organization stand with open source risk management? How are you identifying and securing open source used in your code? Measure your organization against these four levels to find out.
Why should developers care about container security?Eric Smalling
Slides from my talk at SF Bay Cloud Native Containers Meetup Feb 2022 and SnykLive Stranger Danger on April 27, 2022.
https://www.meetup.com/cloudnativecontainers/events/283721735/
Contain your risk: Deploy secure containers with trust and confidenceBlack Duck by Synopsys
Presented on September 22, 2016 by Brent Baude, Principle Software Engineer, Atomic and Docker Development, Red Hat; Randy Kilmon, VP, Engineering, Black Duck
Organizations are increasingly turning to container environments to meet the demand for faster, more agile software development. But a 2015 study conducted by Forrester Consulting on behalf of Red Hat revealed that 53% of IT operations and development decision makers at global enterprises reported container security concerns as a barrier to adoption.
The challenges of managing security risk increase in scope and complexity when hundreds or even thousands of different open source software components and licenses are part of your application code base. Since 2014, more than 6,000 new open source security vulnerabilities have been reported, making it essential to have good visibility into and control over the open source in use in order to understand if any known vulnerabilities are present.
In this webinar, experts from Red Hat and Black Duck will share the latest insights and recommendations for securing the open source in your containers, including protecting them from vulnerabilities like Heartbleed, Shellshock and Venom. You’ll learn:
• Why container environments present new application security challenges, including those posed by ever-increasing open source use.
• How to scan applications running in containers to identify open source in use and map known open source security vulnerabilities.
• Best practices and methodologies for deploying secure containers with trust and confidence.
"This workshop is for pentesters, security researchers or someone looking to get into IoT security but is reluctant due to the wide range of technologies involved and plethora of different tools. While it does require a considerable amount of knowledge in the domain, it is not as difficult as you may think. In this workshop we will introduce you to some of the important concepts and EXPLIoT framework in a very simple way that can be used for the various IoT attack vectors. The primary focus of this workshop is to introduce the attendees to the open source IoT Security Testing and Exploitation Framework - EXPLIoT (https://gitlab.com/expliot_framework/expliot) and enable them to use as well as extend it by writing plugins for new IoT based exploits and analysis test cases. It’s a flexible and extendable framework that would help the security community in writing quick IoT test cases and exploits. The objectives of the framework are:
1. Easy to use
2. Extendable
3. Support for hardware, radio and IoT protocol analysis
EXPLIoT currently supports the following protocols which can be utilized for writing new plugins/exploits:
1. Radio – BLE , Zigbee
2. Network – MQTT, CoAP, DICOM, MODBUS, MDNS, NMAP, TCP, UDP
3. Hardware – CAN, SPI, I2C, UART, JTAG
This talk would give attendees a first-hand view of the functionality, how to use it and how to write plugins to extend the framework."
Why cloud native envs deserve better security - Dima Stopel, Twistlock - Clou...Cloud Native Day Tel Aviv
Traditionally, security teams have been accustomed to investigating incidents and falling back to previous code releases if they detect serious issues. With the rise of modern cloud-native applications and immutable infrastructure, however, security engineers have new solutions at their fingertips. Immutable infrastructure refers to infrastructure with components that are designed to be destroyed and replaced with new versions whenever a change is necessary. This makes immutable infrastructure different from conventional deployment technologies, in which components were typically updated while they were still running rather than being redeployed whenever a change takes place. In this session, Dima Stopel will discuss the changing security landscape and how immutable infrastructure and cloud-native technologies such as containers, can make tedious, risk-prone security workflows a thing of the past.
Integrate Security into DevOps - SecDevOpsUlf Mattsson
1.Security Controls Must Be Programmable and Automated Wherever Possible
2.Implement a Simple Risk and Threat Model for All Applications
3.Scan Custom Code, Applications and APIs
4.Scan for OSS Issues in Development
5.Treat Scripts/Recipes/Templates/Layers as Sensitive Code
6.Measure System Integrity and Ensure Correct Configuration at Load
7.Use Whitelisting on Production Systems, Including Container-Based Implementations
8.Assume Compromise; Monitor Everything; Architect for Rapid Detection and Response
9.Lock Down Production Infrastructure and Services
10.Tokenization and Payment Processing
Monitoring Application Attack Surface to Integrate Security into DevOps Pipel...Denim Group
A web application’s attack surface is the combination of URLs it will respond to as well as the
inputs to those URLs that can change the behavior of the application. Understanding an
application’s attack surface is critical to being able to provide sufficient security test coverage,
and by watching an application’s attack surface change over time security and development
teams can help target and optimize testing activities. This presentation looks at methods of
calculating web application attack surface and tracking the evolution of attack surface over
time. In addition, it looks at metrics and thresholds that can be used to craft policies for
integrating different testing activities into Continuous Integration / Continuous Delivery (CI/CD)
pipelines for teams integrating security into their DevOps practices.
Presented by Tim Mackey, Senior Technology Evangelist, Black Duck Software on August 17.
To use containers safely, you need to be aware of potential security issues and the tools you need for securing container-based systems. Secure production use of containers requires an understanding of how attackers might seek to compromise the container, and what you should be aware of to minimize that potential risk.
Tim Mackey, Senior Technical Evangelist at Black Duck Software, provides guidance for developing container security policies and procedures around threats such as:
1. Network security
2. Access control
3. Tamper management and trust
4. Denial of service and SLAs
5. Vulnerabilities
Register today to learn about the biggest security challenges you face when deploying containers, and how you can effectively deal with those threats.
Watch the webinar on BrightTalk: http://bit.ly/2bpdswg
Securing Container Deployments from Build to Ship to Run - August 2017 - Ranc...Shannon Williams
Security should be integrated into every phase of the container application development life cycle, from build to ship to run. On August 31st, we hosted an online meetup to discuss the issues that need be addressed to achieve continuous security for containers.
The presentation included speakers from Rancher Labs (www.rancher.com), NeuVector (www.neuvector.com) and Black Duck Software (www.blackducksoftware.com) who discussed:
- Best practices for preparing your environment for secure deployment
- How to secure containers during run-time
- Actionable next steps to protect your applications
Applied Security for Containers, OW2con'18, June 7-8, 2018, ParisOW2
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?
Application security meetup k8_s security with zero trust_29072021lior mazor
The "K8S security with Zero Trust" Meetup is about K8s posture Management and runtime protection, ways to secure your software supply chain, Managing Attack Surface reduction, and How to secure K8s with Zero-Trust.
As presented by Tim Mackey, Senior Technical Evangelist at Black Duck Software, at Open Source Open Standards (GovNet) (http://opensourceconference.co.uk/), this deck covers some of the material which operators of open source data centers and users of container and cloud technologies should be aware of when seeking to be security conscious.
Traditionally, when datacentre operators talk about application security, there has been a tendency to focus on issues related to key management, firewalls and data access. By contrast, application developers have a security focus which is more aligned with code analysis and fuzzing techniques. The reality is, secure application deployment principles extend from the infrastructure layer through the application and include how the application is deployed. With the prevalence of continuous deployment, it’s imperative to focus efforts on what attackers’ view as vulnerable; particularly in an environment where new exploits are being disclosed almost daily.
In this session we’ll present:
- How known vulnerabilities can make their way into production deployments
- How vulnerability impact is maximized
- A methodology for ensuring deployment of vulnerable code can be minimized
- A methodology to minimize the potential for vulnerable code to be redistributed
DCSF19 Container Security: Theory & Practice at NetflixDocker, Inc.
Michael Wardrop, Netflix
Usage of containers has undergone rapid growth at Netflix and it is still accelerating. Our container story started organically with developers downloading Docker and using it to improve their developer experience. The first production workloads were simple batch jobs, pioneering micro-services followed, then status as a first class platform running critical workloads.
As the types of workloads changed and their importance increased, the security of our container ecosystem needed to evolve and adapt. This session will cover some security theory, architecture, along with practical considerations, and lessons we learnt along the way.
Using hypervisor and container technology to increase datacenter security pos...Black Duck by Synopsys
As presented by Tim Mackey, Senior Technical Evangelist - Black Duck Software, at LinuxCon/ContainerCon 2016:
Cyber threats consistently rank as a high priority for data center operators and their reliability teams. As increasingly sophisticated attacks mount, the risk associated with a zero-day attack is significant. Traditional responses include perimeter monitoring and anti-malware agents. Unfortunately, those techniques introduce performance and management challenges when used at large VM densities, and may not work well with containerized applications.
Fortunately, the Xen Project community has collaborated to create a solution which reduces the potential of success associated with rootkit attack vectors. When combined with recent advancements in processor capabilities, and secure development models for container deployment, it’s possible to both protect against and be proactively alerted to potential zero-day attacks. In this session, we’ll cover models to limit the scope of compromise should an attack be mounted against your infrastructure. Two attack vectors will be illustrated, and we’ll see how it’s possible to be proactively alerted to potential zero-day actions without requiring significant reconfiguration of your datacenter environment.
Technology elements explored include those from Black Duck, Bitdefender, Citrix, Intel and Guardicore.
Here Be Dragons: Security Maps of the Container New WorldC4Media
Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1KjxPiO.
Josh Bregman explores some of the unique security challenges created by both the development workflow and application runtime, explains why and how the current approaches in SecDevOps 1.0 are insufficient, and how SecDevOps 2.0 techniques including Software Defined Firewalls (SDF) provide a promising path forward for all parties involved. Filmed at qconnewyork.com.
Josh Bregman is Information Security Architect and Executive Vice President for Technical Sales at Conjur Inc.
Hacking Samsung's Tizen: The OS of Everything - Hack In the Box 2015Ajin Abraham
Samsung’s first Tizen-based devices are set to launch in the middle of 2015. This paper presents the research outcome on the security analysis of Tizen OS and it’s underlying security architecture. The paper begins with a quick introduction to Tizen architecture and explains the various components of Tizen OS. This will be followed by Tizen’s security model where application sandboxing and resource access control will be explained. Moving on, an overview of Tizen’s Content Security Framework which acts as an in-built malware detection API will be covered.
Various vulnerabilities in Tizen will be discussed including issues like Tizen WebKit2 address spoofing and content injection, Tizen WebKit CSP bypass and issues in Tizen’s memory protection (ASLR and DEP).
DevOpsDaysRiga 2017: Chris Van Tuin - A DevOps State of Mind: Continuous Secu...DevOpsDays Riga
With the rise of DevOps, containers are at the brink of becoming a pervasive technology in Enterprise IT to accelerate application delivery for the business. When it comes to adopting containers in the enterprise, Security is the highest adoption barrier.
From Containerized Application to Secure and Scaling With KubernetesShikha Srivastava
Discuss following:
What does it really take to make sure your application is production ready?
With new privacy regulations being added, many aspects need to be taken into account when deciding when to deliver your final application is ready for production.
Can your application handle multiple users with different levels of access?
Can you extend your application to use existing authentication and authorization platforms?
Have you invested in using Mutual TLS for communication between components?
How do you manage the certificates and passwords used within your product?
Is CICD your friend or your enemy when it comes to delivering your product?
Have you considered the availability and scalability of the application?
Containers Anywhere with OpenShift by Red Hat - Session Sponsored by Red HatAmazon Web Services
OpenShift is Red Hat's Platform-as-a-Service (PaaS) that lets developers quickly develop, host, and scale Docker container-based applications. OpenShift enables a uniform and standardised approach to container management across all hosting options including AWS/EC2 and other private/public cloud and on/off-premise variants.
At this session, you will learn how Red Hat's enterprise clients are using OpenShift to enable their digital transformation initiatives. Examples will cover how realising a hybrid cloud strategy can simplify and reduce the risk of migrating and transitioning application workloads to containers in the cloud.
Speaker: Andrea Spanner, Red Hat Asia Pacific Pty Ltd
With the launch of our Helix source code management and content collaboration platform, we’ve added a lot of new capabilities to our version management system. Get an overview our new DVCS capabilities, Git Management, Threat Detection and more.
A question of trust - understanding Open Source risksTim Mackey
As presented at the Bay Area Cyber Security Meetup on January 25th, 2018.
Open source development paradigms have become the norm for most software development. This is regardless of whether you're making the next great IoT device, a new container microservice, or desktop application. While open source components are often viewed as free, and definately help solve problems in a scalable way, using them in a secure manner requires an understanding of how open source development really works.
In this sesssion, I covered how secure development practices with data center regulations can benefit from an understanding of open source development. Specifically, we looked at fork management, community engagement and patch management. We ended with an open source maturity model.
As presented via webinar.
The Open Source 360 survey is in its 11th year and surveyed over 800 IT professionals about their use of open source components and technologies. In prior years, this survey was known as the Future Of Open Source.
Key takeaways include:
- Open Source usage is growing within global organizations
- Organizations recognize risks of consumption exist
- Tooling to keep pace with risks is limited
- Contributions to project communities are key to success
The XenServer virtualization platform is used by well over 100,000 organizations to fulfill their IT objectives. Common scenarios include traditional server virtualization such as that found with VMware vSphere, delivery of large scale cloud services via Apache CloudStack or OpenStack, and as a platform for high performance desktop virtualization through XenDesktop. These use cases all have requirements of scale and manageability which imply solid deployments.
The content in this deck was presented in workshop form at FOSSETCON in 2015. Much of the information contained will work for any XenServer version, but XenServer 6.5 was covered. The audience was assumed to have some familiarity with virtualization concepts, but no assumptions about XenServer was made. Core concepts covered included; storage design, network design and operations, scalability and failure domains, as well as core features such as virtualized graphics.
XenServer Virtualization In Cloud EnvironmentsTim Mackey
= As presented at the CloudStack Silicon Valley Meetup in September 2015. =
XenServer is a virtualization platform which has been deployed in a variety of industries and to support a multitude of workloads. In this session we discuss some of the components which make it valuable not just for traditional server and desktop virtualization, but also within "the cloud". This includes discussion of VM density, network scalability, containers (such as Docker) and GPU virtualization. We end with coverage of how XenServer templates are represented within Apache CloudStack.
Selecting the correct hypervisor for CloudStack 4.5Tim Mackey
Apache CloudStack supports multiple hypervisors out of the box, and the obvious question is which hypervisor is best for CloudStack. In this session we cover core CloudStack components such as networking, storage and virtualization functions to present which hypervisor is able to meet a given requirement. The core take-away is that with an understanding of the services to be delivered the correct hypervisor, or hypervisors, can be selected with relative ease. This deck is as delivered at CloudStack Days 2015 in Seattle.
User Transparent Service Migration to the CloudTim Mackey
While creating a cloud such as OpenStack is fairly easy, template management is more challenging. In this session we discuss how systems engineering and tooling can be combined to allow legacy infrastructure and virtual machines to be converted to templates without downtime. These templates can then be deployed within the cloud and users migrated with minimal interruption. This deck is as delivered at CloudOpen 2015 in Seattle.
CloudOpen Japan - Controlling the cost of your first cloudTim Mackey
As presented at CloudOpen Japan in Tokyo in 2015.
Today everyone is talking about clouds, and some are building them, but far fewer are operating successful clouds. In this session we'll examine a variety of paradigm shifts must IT make when moving from a traditional virtualization and management mindset to operating a successful cloud. For most organizations, without careful planning the hype of a cloud solution can quickly overcome its capabilities and existing best practices can combine to create the worst possible cloud scenario -- a cloud which isn't economical to operate, and which is more cumbersome to manage than a traditional virtualization farm. Key topics covered will include; transitioning the operational paradigm, the impact of VM density on operations and network management, and preventing storage cost from outpacing requirements.
Taming the cost of your first cloud - CCCEU 2014Tim Mackey
Today everyone is talking about clouds, and a few are building them, but far fewer are operating successful clouds. In this session we'll examine a variety of paradigm shifts IT makes when moving from a traditional virtualization and management mindset to operating a successful cloud. For most organizations, without careful planning the hype of a cloud solution can quickly overcome its capabilities and pre-existing best practices can combine to create the worst possible cloud scenario -- a cloud which isn't economical to operate, and which is more cumbersome to manage than a traditional virtualization farm.
Key topics covered include:
- Successful transition of operational and management paradigm
- How the VM density of clouds change Ops
- What it means to monitor the network in a cloud environment, at hyper-dense virtualization levels
- Preventing storage costs from outpacing delivery costs
Using Packer to Migrate XenServer Infrastructure to CloudStackTim Mackey
When adopting IaaS cloud solutions, one of the biggest challenges will be template management. Creating that first template can easily be more challenging that deploying the cloud software itself. In this presentation two options are presented for template creation, using a kickstart file or cloning a running VM with Packer from packer.io as the core framework.
This presentation was delivered at CloudStack Days 2015 in Austin Texas. Two demos were given. The first demo used an existing XenServer environment to create a golden master from ISO and kickstart file, then automatically upload it to a CloudStack management server for deployment. The second demo cloned a running VM and created a template which was then uploaded to CloudStack. In the case of the running VM, migration occurred without any user interruption. The VM in question was a CentOS 7 image, and the hypervisor for both source infrastructure and CloudStack compute was XenServer based
Hypervisor Selection in Apache CloudStack 4.4Tim Mackey
Building an infrastructure as a service cloud involves a number of technology decisions, many of which could have unforeseen impact. Hypervisors form the core of an IaaS cloud, and whether you are a fan of Microsoft Hyper-V, VMware vSphere, KVM in any Linux variant or XenServer from Citrix, each of these hypervisors provide unique capabilities within an Apache CloudStack 4.4 based cloud.
OSCON2014: Understanding Hypervisor Selection in Apache CloudStackTim Mackey
A presented at OSCON 2014, this deck covers the matrix of capabilities each supported hypervisor brings to the Apache CloudStack table when building a cloud.
Make your first CloudStack Cloud successfulTim Mackey
As presented at the 2014 CloudStack Collaboration Conference in Denver (CCCNA14), this deck covers some of the decision points impacting a successful deployment of CloudStack within your organization. Critical elements such as storage and networking are discussed to create a blueprint which seeks to remove some of the learning curve associated with the transition from data center management to cloud management.
Decisions behind hypervisor selection in CloudStack 4.3Tim Mackey
As presented at the 2014 CloudStack Collaboration Conference in Denver (CCCNA14), this deck covers the matrix of functions and features within each supported hypervisor in CloudStack 4.3. This deck forms an excellent reference document for those seeking to provide multi-hypervisor support within their Apache CloudStack based cloud, and for those seeking to determine which feature elements are supported by a given hypervisor.
Hypervisor Selection in CloudStack and OpenStackTim Mackey
Deploying a successful cloud is a function of the capabilities of both the virtualization layer and the cloud orchestration platform. In this deck, presented at the annual Deep Dive Day hosted by the Boston Virtualization User Group (virtg.com), I covered CloudStack 4.3 and OpenStack Havana. The deck doesn't seek to define a "best" option, but to provide the information data center architects and system administrators require regardless of preference for KVM, XenServer, vSphere or Hyper-V.
Hypervisor Capabilities in Apache CloudStack 4.3Tim Mackey
Apache CloudStack 4.3 adds support for clouds built using Microsoft Hyper-V, in addition to supporting VMware vSphere, Citrix XenServer, KVM, Oracle VM, Linux Containers and bare metal options. This deck covers the decision points impacting the design of CloudStack 4.3 clouds, and their relationship with hypervisor choices.
Presented at Build a Cloud Day co-located with SCaLE 12x in February 2014.
CloudStack is one of many cloud orchestration platforms which can deliver IaaS clouds. One of the key capabilities of CloudStack is its ability to support multiple hypervisors in a CloudStack cloud. So whether your virtualization preference is VMware vSphere, KVM, Citrix XenServer or Linux Containers (LXC), you can build highly scalable clouds. While basic functionality is common across all hypervisors, many features are implemented differently on each. This paper presents the capabilities of CloudStack which can be enabled based on your hypervisor selection
Planning a successful private cloud - CloudStack Collaboration Europe 2013Tim Mackey
So your boss just asked you to build a private cloud. Now what? Successful private clouds require a bit of planning, and your existing best practices may need to be adjusted. This deck covers some of the issues you'll face, or be aware of, as you migrate from an existing data center operation to one which is more "cloud-like". Some things may seem obvious, but there are aspects to network and storage design which impact success. This deck draws from my experience in building my first CloudStack cloud in early 2012 and has applicability to anyone seeking to deliver cloud services.
Multi-cluster Kubernetes Networking- Patterns, Projects and GuidelinesSanjeev Rampal
Talk presented at Kubernetes Community Day, New York, May 2024.
Technical summary of Multi-Cluster Kubernetes Networking architectures with focus on 4 key topics.
1) Key patterns for Multi-cluster architectures
2) Architectural comparison of several OSS/ CNCF projects to address these patterns
3) Evolution trends for the APIs of these projects
4) Some design recommendations & guidelines for adopting/ deploying these solutions.
1.Wireless Communication System_Wireless communication is a broad term that i...JeyaPerumal1
Wireless communication involves the transmission of information over a distance without the help of wires, cables or any other forms of electrical conductors.
Wireless communication is a broad term that incorporates all procedures and forms of connecting and communicating between two or more devices using a wireless signal through wireless communication technologies and devices.
Features of Wireless Communication
The evolution of wireless technology has brought many advancements with its effective features.
The transmitted distance can be anywhere between a few meters (for example, a television's remote control) and thousands of kilometers (for example, radio communication).
Wireless communication can be used for cellular telephony, wireless access to the internet, wireless home networking, and so on.
This 7-second Brain Wave Ritual Attracts Money To You.!nirahealhty
Discover the power of a simple 7-second brain wave ritual that can attract wealth and abundance into your life. By tapping into specific brain frequencies, this technique helps you manifest financial success effortlessly. Ready to transform your financial future? Try this powerful ritual and start attracting money today!
ER(Entity Relationship) Diagram for online shopping - TAEHimani415946
https://bit.ly/3KACoyV
The ER diagram for the project is the foundation for the building of the database of the project. The properties, datatypes, and attributes are defined by the ER diagram.
The How and Why of Container Vulnerability Management
1. The How and Why of
Container Vulnerability
Management
OpenShift Commons
2. #whoami – Tim Mackey
Current roles: Senior Technical Evangelist; Occasional coder
• Former XenServer Community Manager in Citrix Open Source Business Office
Cool things I’ve done
• Designed laser communication systems
• Early designer of retail self-checkout machines
• Embedded special relativity algorithms into industrial control system
Find me
• Twitter: @TimInTech ( https://twitter.com/TimInTech )
• SlideShare: slideshare.net/TimMackey
• LinkedIn: www.linkedin.com/in/mackeytim
4. Vulnerability Management Implies Data Breach Management
89% of data breaches had a
financial or espionage motive
Legal costs and forensics dominate
remediation expenses
Source: Verizon 2016 Data Breach Report
10. CLOSED SOURCE COMMERCIAL CODE
• DEDICATED SECURITY RESEARCHERS
• ALERTING AND NOTIFICATION INFRASTRUCTURE
• REGULAR PATCH UPDATES
• DEDICATED SUPPORT TEAM WITH SLA
OPEN SOURCE CODE
• “COMMUNITY”-BASED CODE ANALYSIS
• MONITOR NEWSFEEDS YOURSELF
• NO STANDARD PATCHING MECHANISM
• ULTIMATELY, YOU ARE RESPONSIBLE
Who is Responsible for Code and Security?
11. Knowledge is Key. Can You Keep Up?
glibc
Bug
Reported
July 2015
Vuln: CVE-2015-7547: glibc getaddrinfo stack-based
buffer overflow
12. Knowledge is Key. Can You Keep Up?
glibc
Vuln
Introduced
May 2008
glibc
Bug
Reported
July 2015
CVE-2015-
7547
CVE
Assigned
Feb 16-2016
Low Security Risk
Vuln: CVE-2015-7547: glibc getaddrinfo stack-based
buffer overflow
13. Knowledge is Key. Can You Keep Up?
glibc
Vuln
Introduced
May 2008
CVE-2015-
7547
CVE
Assigned
Feb 16-2016
glibc
Bug
Reported
July 2015
National
Vulnerability
Database
Vuln
Published
Feb 18-2016
Moderate Security Risk
Low Security Risk
Vuln: CVE-2015-7547: glibc getaddrinfo stack-based
buffer overflow
14. Knowledge is Key. Can You Keep Up?
glibc
Vuln
Introduced
National
Vulnerability
Database
Vuln
Published
You
Find It
May 2008
CVE-2015-
7547
CVE
Assigned
Feb 16-2016 Feb 18-2016
glibc
Bug
Reported
July 2015
Patches
Available
You
Fix It
Highest Security Risk
Moderate Security Risk
Low Security Risk
Vuln: CVE-2015-7547: glibc getaddrinfo stack-based
buffer overflow
19. Baseline to Limit the Scope of Compromise
• Enable Linux Security Modules
• SELinux
• --selinux-enabled on Docker engine, --security-opt=“label:profile”
• Apply Linux kernel security profiles
• grsecurity, PaX and seccomp protections for ALSR and RBAC
• Adjust privileged kernel capabilities
• Reduce capabilities with --cap-drop
• Beware –cap-add and –privileged=false, and CAP_SYS_ADMIN
• Use a minimal Linux host OS
• Red Hat Enterprise Linux Atomic Host 7
• Reduce impact of noisy neighbors
• Use cgroups to set CPU shares and memory
20. Red Hat Enterprise Linux Atomic Host 7
• What is Atomic Host?
• Optimized RHEL7 variation designed for use with Docker
• Uses SELinux for safeguards
• Provides atomic upgrade and rollback capabilities via rpm-ostree
• Pre-installed with Docker and Kubernetes
• Atomic App and Atomic Nulecule
• Provides a model for multi-container application definition
• Supports Docker, Kubernetes, OpenShift and Mesos
• OpenShift artifacts run natively or via atomic provider
• Provides security compliance scan capabilities
21. Container Source Trust
Red Hat Atomic Host
AtomicApp
AtomicApp
AtomicApp
Red Hat Registry
MySQL
Redis
Jenkins
Docker Hub
DockerContainer
DockerContainer
DockerContainer
DockerContainer
DockerContainer
Third Party and Custom
Problem: Who to trust, and why?
• Trusted source?
• Unexpected image contents
• Locked application layer
versions (e.g. no yum update)
• Layer dependencies
(monolithic vs micro-services)
• Validated when?
22. OpenSCAP vs. Black Duck Hub
OpenSCAP
• Profile driven compliance policy engine
• Vendor vulnerability data is but one component of policy
• Integrated directly with Red Hat Atomic
• Usage: atomic scan --scanner openscap {container id}
Black Duck Hub integration with Red Hat Atomic
• Broad vulnerability data for most open source components
• Covers vulnerability, license compliance and operational risk
• Integrated with Red Hat Atomic
• Rich tooling integration for development teams
• Installed via: atomic install blackducksoftware/atomic
• Usage: atomic scan --scanner blackduck {container id}
24. Risk Mitigation Shrinks Scope of Compromise
Open source license compliance
• Ensure project dependencies are understood
Use of vulnerable open source components
• Is component a fork or dependency?
• How is component linked?
Operational risk
• Can you differentiate between “stable” and “dead”?
• Is there a significant change set in your future?
• API versioning
• Security response process for project
25. 7 of the top 10
Software Companies
(44 of the top 100)
6 of the top 8
Mobile Handset Vendors
6 of the top 10
Investment Banks
24
Countries
250+
Employees
1,800Customers
Who is Black Duck Software?
27Founded
2002
26. 8,500
WEBSITES
350
BILLION LINES OF CODE
2,400
LICENSE TYPES
1.5
MILLION PROJECTS
76,000
VULNERABILITIES
• Largest database of open source project
information in the world.
• Vulnerabilities coverage extended through
partnership with Risk Based Security.
• The KnowledgeBase is essential for identifying
and solving open source issues.
Comprehensive KnowledgeBase
27. Black Duck Hub Security Architecture
Hub Scan1 File and Directory Signatures2 Open Source
Component Identified
3
Hub Web Application
Black Duck
KnowledgeBase
On Premises Black Duck Data Center
28. We Need Your Help
Knowledge is power
• Know what’s running and why
• Define proactive vulnerability response process
• Don’t let technology hype cycle dictate security
Invest in defense in depth models
• Don’t rely on perimeter security to do heavy lifting
• Do look at hypervisor & container trends in security
• Make developers and ops teams part of the solution
• Focus attention on vulnerability remediation
Together we can build a more secure data center
29. Free Black Duck Container Tools
Free Docker Container Security Scanner
• https://info.blackducksoftware.com/Security-Scan.html
14 Day Free Trial to Black Duck Hub
• https://info.blackducksoftware.com/Demo.html
• Red Hat Atomic Host Integration (Requires Black Duck Hub)
1. atomic install blackducksoftware/atomic
2. atomic scan --scanner blackduck [container]
http://www.istockphoto.com/photo/computer-crime-concept-gm516607038-89059287?st=9174601
http://www.verizonenterprise.com/verizon-insights-lab/dbir/2016/
Every year since 2008, Verizon have published a report on the attempted data breaches occurring within their data centers. For 2015, they found close to 90% of them had either a financial or espionage component to them. This report is well worth the read, and there are a few key findings in this report we should all be aware of.
Costs of data breaches are heavily skewed towards legal consultation and forensics, and not to the public components of credit monitoring or lawsuits
Despite some vulnerabilities having been public for years, there remain vulnerable components in use
Some of those components simply may not have a patch forthcoming for a variety of reasons.
Despite years of organizations spending energy protecting against attacks, it remains up to the attacker to define what’s valuable. Consider the case of ransomware. A police department in the town next to where I live was subjected to a raonsomeware attack. For roughly 500 USD in bitcoin, the attackers would decrypt the booking and evidence records they had just crypto locked. As an attacker, they likely had no knowledge of who they had attacked or what they had locked up. What mattered was the ransom, and that they had a police organization’s files didn’t factor into the equation.
To recap something we already know – investment is skewed. Attackers target applications while we invest in perimeter defenses. This is a reactive strategy built on an assumption that a gatekeeper will always be better, but fails to understand the reality of what can happen if you’re already on the other side of the wall.
Let’s take a little bit of time and look at how an attack is created. Potential attackers have a number of tools at their disposal, and use a number of different tactics. In this case, the attacker wishes to create an attack on a given component. In order to be effective, they have two primary models. First they can actively contribute code in a highly active area of the component with an objective of planting a back door of some form. The hope being that their code will fail to be recognized as suspect given how quickly the area of code is evolving.
Second they can look for areas of code which are stable, and the longer they’ve bene stable, the better. The reason for this is simple, old code is likely written by someone who isn’t with the project any longer, or perhaps doesn’t recall all assumptions present at the time the code was written. After all, its been long understood that even with the best developers, assumptions change and old code doesn’t keep up.
The goal in both cases being to create an attack against the component, so they test, and fail, and iterate against the component until they’re successful or move on. Assuming they’re successful, they create a deployment tool and document the tool for others. Of course, given the publicity received by some recent vulnerabilities, a little PR goes a long way.
Now there are responsible researchers who follow a similar workflow, and they legitimately attempt to work with component creators to disclose vulnerabilities. They too will publish results, but are less interested in creating the an attack beyond a proof of concept.
http://www.istockphoto.com/photo/person-in-hooded-sweater-using-a-laptop-on-wooden-table-gm464503138-58544934?st=cf78f31
http://www.istockphoto.com/photo/cloud-computing-gm518556682-90104967
For example, if we have a datacenter filled with servers, and each server has virtual infrastructure which includes virtual networking and security services, we already have multiple layers of perimeter defenses. If we then add in container VMs which run a minimal OS upon which we load up some containers, we have a pretty good model for where some datacenters are today.
If we then assume an attacker was able to compromise a container, now what? They’re on the other side of the various perimeters, and can attack from the inside. The big question being precisely how much damage could that attack create, and how would you know?
This is the opportunity we have, and the people who are responsible for this are practitioners of a philosophy known as DevOps.
https://www.cesg.gov.uk/guidance/open-source-software-%E2%80%93-exploring-risk-good-practice-guide-38
If you’re using commercial software, the vendor is responsible for best practice deployment guidance, the notification of any security vulnerabilities and ultimately patches and workarounds for disclosed vulnerabilities. This is part of the deliverable they provide in return for their license fee.
If you’re using open source software, that process becomes partly your responsibility. To illustrate the level of information you have to work with, let’s look at a media-wiki maintenance release from December 2015.
“various special pages resulted in fata errors” – this clearly is something which needs resolution, but which pages? How do you test?
“1.24.6 marks the end of support for 1.24.x” – this is good to know, but I hope it was published elsewhere.
“However, 1.24.5 had issues (along with other versions) so it was thought fair to fix them” – This is a good thing, but can we expect this treatment in the future? From the title, we also have a fix for 1.23.x, but what other versions?
https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
https://sourceware.org/bugzilla/show_bug.cgi?id=18665
https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7547 (published via US-CERT)
http://cve.mitre.org/cve/cna.html
https://openclipart.org/detail/200681/primary-patch
https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
https://sourceware.org/bugzilla/show_bug.cgi?id=18665
https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7547 (published via US-CERT)
http://cve.mitre.org/cve/cna.html
https://openclipart.org/detail/200681/primary-patch
https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
https://sourceware.org/bugzilla/show_bug.cgi?id=18665
https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7547 (published via US-CERT)
http://cve.mitre.org/cve/cna.html
https://openclipart.org/detail/200681/primary-patch
https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
https://sourceware.org/bugzilla/show_bug.cgi?id=18665
https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7547 (published via US-CERT)
http://cve.mitre.org/cve/cna.html
https://openclipart.org/detail/200681/primary-patch
https://www.youtube.com/watch?v=hkryI6eapOA
Datadog, a systems monitoring company, looked at the use of containers from 10,000 of their customers. There are multiple observations in the report, but the most significant is yet more data supporting the assertion containers are now production ready. This doesn’t mean we want to abandon other aspect of the DevOps story, rather it means we need to ensure we’ve a completeness to the story, and that we need to be a serious player in the container space.
If you assume from the outset your containers will be compromised, what would you do differently? What could you do to make life much harder to mount an attack from a compromised container?
The first item everyone should have on their list is to enable the SELinux and AppArmor security modules for the distro you’re using as a base. For SELinux, you specify that it’s enabled on the command line for Docker Engine, and then on the container you specify a security option representing the profile you want to use.
Now that you have some security modules in place, you’re in better shape, but you can still make it much harder to mount a proper attack. Consider for example an attacker who recognizes they’re in a container, and assumes that means there probably are multiple containers with the same profile. Armed with that knowledge, one of the easiest ways to make the life of an attacker harder is to randomize the memory load location. That’s where kernel security profiles come into play. Grsecurity, PaX and seccomp enable roles based access and address randomization upon load capabilities. Net of this, where the executable code lives in memory changes, and that makes it harder to know if you’ve created a viable attack or not.
Now the Docker people have done a great job over the years in locking down the level of privileged access you get from within a container. In part, this is done using what’s known as kernel capabilities. Kernel capabilities offer a granular level of control over the types of operations you want the kernel to perform. Consistent with the concept of least privilege, you don’t want to ask for more rights than you need. If you find the defaults are providing more access than your application requires, you can pare things back using the –cap-drop option. Of course, it’s entirely possible you might need more rights, but if you find you need to disable priviledged access, or want to set the CAP_SYS_ADMIN flag, beware you’re effectively giving the container the equivalent of root access.
Lastly, from a security perspective, you can choose to use a minimal Linux distro such as Atomic or CoreOS, but you still will want to pay attention to the options I’ve just outlined.
So now that you’ve limited the access a potential attacker has to system services, you still have to contend with other types of havoc. A perfect example of this is the concept of a noisy neighbor. Most of us have had the experience of having someone in a neighboring space behave in an annoying manner. In the case of computing, the annoying neighbor can be one which consumes excessive memory or processing time. Limiting the scope of interference is very easy. All you need to do is define some CPU shares and memory limits for the container and set them during launch.
Image source: US Navy 040814-N-5781F-033 Storekeeper 2nd Class Daniel Mina
Hub is based on a 3 part architecture:
Scan Client – scans directories and artifact files creating “code prints” that uniquely but confidentially identify the files & directories contained in them
Web Application – This is the main user interface and logic center for Hub.
KnowledgeBase – This is a repository for open source component, license, and vulnerability information
The code prints recoreded by the scan client are compared to reference code prints in the KnowledgeBase to identify open source components, versions, and origins. No source or binary code is ever uploaded.
Docker Container Security Scanner
https://info.blackducksoftware.com/Security-Scan.html
14 Day Free Trial to Black Duck Hub
https://info.blackducksoftware.com/Demo.html
Red Hat Atomic Host Integration (Requires Black Duck Hub)
atomic scan --scanner blackduck [container]