All data breaches expose some type of IT (Information Technology) or OT (Operating Technology) system vulnerability. Cybersecurity professionals then need to evaluate and determine appropriate responses for themselves and their clients. It might be patching software, revising work processes or altering incident response techniques.
On April 25, 2019, Docker Hub discovered unauthorized access to a single Hub database. The breach itself was relatively minor only exposing 190,000 accounts - less than 5 % of Hub users. The issue here is not the breach itself but what it represents.
Docker Hub is one of the largest cloud-based libraries of Docker container images. This online repository allows developers to isolate applications and create independent ‘containers’ which can run across a multitude of operating environments and programming languages. These images can be used privately within an organization, but also shared publicly allowing developers to create software architectures faster and insuring they are not locked into any specific infrastructure.
Docker was named a Leader in The Forrester New Wave™: Enterprise Container Platform Software Suites, Q4 2018 report and as such, is an emerging technology that is gaining widespread acceptance and usage. Container technology is compelling because standardized components can be built and shared making the entire application lifecycle more efficient and providing the ability for applications to run anywhere.
A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application – the code itself, a machine OS (Operating System) kernel and any system tools or software libraries utilized. Multiple containers can then run on the same machine and will share the OS kernel with the other containers.
This is similar to a Virtual Machine (VM) but in that case, the hardware is virtualized and each VM includes a separate copy of the OS.
Why a Docker Breach is so Impactful
A Docker Hub contains official and certified images collected from trusted sources that can be reused and shared across the wider software developer community. The key word here is ‘trusted’. What happens when a trusted supplier is breached?
Also, multiple ICS vendors are moving towards internet enabled service updates and automated patch solutions that take advantage of that external connectivity to enable software updates without requiring costly service tech onsite visits.
Attacks on containers used in shared cloud environments can lead to collateral damage for software developers. Collateral damage is when a victim is impacted without being the primary target. Attacks on a common cloud-based repository of software components will impact any downstream user. Using services such as automated updates can introduce unanticipated security vulnerabilities that may take some time to be reported as a vulnerability and quantified in a repository such as the NVD (National Vulnerability Database) maintained by NIST (National Institute of Standards & Technology).
Given the widespread usage of their products and services, OEM (Original Equipment Manufacturers) and software and hardware vendors are at particular risk as their solutions are deployed into production environments and scaled across enterprises.
In addition, developers may have enabled Autobuilds to make sure their applications are including the latest versions of software libraries into their software packages. Attackers compromising container artifacts such as tokens and access keys are looking to be able to inject malicious code into auto-built containers. This might also provide attackers with a path into protected code repositories maintained by organizations.
How to address these concerns? Some safety tips include:
- Establish core cyber hygiene practices
Sound cybersecurity always starts with having a strong cyber hygiene posture in place. The basics should always be in place before worrying about the more advanced threats that utilization of container technologies might enable. A comprehensive organization security policy should be in place, critical data assets should be identified, and their safety given top priority.
Also make sure regular backup and restore procedures are in place and exercised on a regular basis. Often overlooked is the time it takes to restore images across hundreds or thousands of compromised devices and machines. Any restore operation will necessarily take IT components or OT devices down for some period of time.
- Analyze software patch update process
Do you know how your IT and OT environments handle the software patch process? How current is your current software baseline with regards to new available software patches? This is an increasingly important consideration as new threats are identified and mitigated through new patches. Any organization running older software is potentially exposed to malware that would execute on those software versions that have subsequently been patched by the OEM or software vendor.
Any automated updates should only be pulled from isolated trusted servers in an appropriate network zone that enables the ability to verify the accuracy and integrity of the software patch itself.
- Insure utilized container images are contained in secure repositories
Repositories such as Docker Hub provide the ability to create, maintain and operate private registries of images. This serves to enforce sound CM (Configuration Management) practices and insure adjacent information such as metadata or security dashboard metrics is not compromised along with the source code itself.
Private registries can be established which allow organizations to only share and reuse containers that have been approved and tested by internal cyber staff.
The transfer of container data using services that offer encryption is not sufficient if the components being encrypted are already compromised. Vendors should offer images that are cryptographically signed at build time preventing such things as man-in-the middle attacks and insuring the integrity of data in motion.
- Analyze security logs on a regular basis
One of the key intents of having security log data generated and stored is to be able to conduct forensic analysis after the fact. Any organization using container technologies should be able to take a look at the specific images they are utilizing and determine if any non-authorized access has taken place.
- Scan container images for security vulnerabilities
Docker Security Scanning indexes components and insures only approved modules are put into production. Components can be scanned against a known CVE (Common Vulnerability Enumeration) database and generate a report providing insight to the vulnerability scanning results.
This type of action can prevent newly emerging threats such as container spoofing where an organization ends up running unintended containers containing malicious code.
New IT and software development technologies emerge to solve existing problems or to bring some type of increased functionality or to reduce development time or to reduce operating costs. These technologies are often deployed without adequate consideration of the cybersecurity aspects and how usage of new technologies brings new security vulnerabilities.
Understanding how container technologies are implemented in your organization allows a proper cyber risk evaluation to be conducted with the goal of mitigating any new introduced security vulnerabilities. Only using containers from trusted vendors and making sure constituent parts are digitally signed prevents running containers that have been tampered with.
Container technologies are making a huge impact across multiple operating environments. The challenge is to insure any upstream supply chain data breaches do not compromise the integrity of your deployed applications and allow OT to conduct ongoing safe operations.