A Single Partner for Everything You Need Optiv works with more than 450 world-class security technology partners. By putting you at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can.
We Are Optiv Greatness is every team working toward a common goal. Winning in spite of cyber threats and overcoming challenges in spite of them. It’s building for a future that only you can create or simply coming home in time for dinner. However you define greatness, Optiv is in your corner. We manage cyber risk so you can secure your full potential.
Registry Risks Breadcrumb Home Insights Blog Registry Risks January 21, 2020 Registry Risks Gaining Visibility into NIST SP 800-190, Part Four In my previous post (Part Three: Image Risks) I described how native AWS tools and third-party solutions can address image risks identified in section 3.1 of NIST SP 800-190 Application Container Security Guide. This post will dive into section 3.2 (Registry Risks) and 4.2 (Registry Countermeasures). 3.2.1 Insecure connections to registries: The image registry is the location of image builds used in container deployments. Similar to communication with other sensitive data, connections to image registries should be maintained in a secure manner. These registries can contain sensitive information and should be treated as connecting to sensitive data. NIST provides the following guidance on risks and countermeasures: 3.2.1 Example Risks HTTP access to private registries Man-in-the-middle Credential theft 4.2.1 Countermeasures Connection to registries over encrypted channels HTTPS AWS As described in the preceding blog post on Kubernetes Test Lab, these registries are located within each project of the GitLab server, which is an EC2 instance. The use of HTTPS access to project registries was defined on the GitLab server. However, security group inbound/outbound access restrictions to include only secure connections could be placed on the EC2 instance of the GitLab server as a way of mitigating some risk. In terms of what AWS offers for connection logging to our registry, VPC flow logs provide some connection visibility but it isn’t perfect and takes some work to find. Below is the output of a CloudWatch search from VPC flow that was filtered based on the GitLab server and the port 4567, used for the registry. Unfortunately, it is difficult to discern if the connection was encrypted. The number 6 in the protocol only tells us that it was a TCP connection. Prisma Cloud/Third-Party Tools Prisma Cloud (formerly Twistlock) doesn’t have the ability to enforce registries to enable HTTPS communication. However, policies can be created within the product to prevent the pull of images from unknown registries. 3.2.2 Stale images in registries: Stale images are those that are old and potentially running out-of-date software. The hosting of stale images does not present immediate risk unless that image is used by a container. NIST provides the following guidance on risks and countermeasures: 3.2.2 Example Risks Running out-of-date and potentially vulnerable software Older images are at risk of newly discovered vulnerabilities 4.2.2 Countermeasures Prune registries of unsafe or vulnerable images Use of immutable names for version specification AWS AWS did not have visibility into the image registries for this project. Amazon Elastic Container Registry (ECR) was not used for this project. Prisma Cloud Prisma Cloud doesn’t report on stale images but would have the ability to prune images using the API integration. Other Stale images can be found using the docker images command: docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.ID}}\t{{.CreatedAt}}\t{{.Size}}" Use filters to prune images within Docker. As an example, the image below shows how to delete all images before 10-13-2019, about 30 days from when this image was taken. docker image prune -a –force –filter “until=2019-10-13T00:00:00" 3.2.3 Insufficient authentication and authorization restrictions: Images within a registry may contain sensitive data. The lack of authentication or authorization restrictions to private registries could pose multiple risks to an organization. NIST provides the following guidance on risks and countermeasures: 3.2.3 Example Risks Intellectual property loss due to unauthorized access Images can be removed or replaced by malicious users leading to a wider compromise 4.2.3 Countermeasures Connection to registries over encrypted channels HTTPS AWS Our registries were located within each project on the GitLab server. Access to the registries are defined on the GitLab server, and authentication lockdown can be performed there. Above and beyond that, security group inbound/outbound access restrictions could be placed on the EC2 instance of the GitLab server as a way of mitigating some risk and only allowing needed groups. Prisma Cloud Prisma Cloud can integrate with an organization’s directory service, like Active Directory, to define policy around who can push to and pull from defined registries. The example policy below prevents all members in the PRS group from pushing images to the registry. Hopefully this analysis proves helpful to security practitioners and others that are looking for methods to obtain visibility into registry risks. Stay tuned for the next blog post in this series, which will cover orchestrator risks and countermeasures. By: Dan Kiraly Senior Research Scientist | Optiv Dan Kiraly is senior research scientist on Optiv’s R&D team. In this role he's responsible for use case development and the vetting of security products for Optiv. Share: NIST Containers CyberOps NIST Series