Registry Risks

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).

 

Optiv CI Pipeline Lab Image

 

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.

 

CloudWatch

 

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}}"

 

Stale Images Docker Images Command

 

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"

 

Prune Images within Docker

 

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.

 

Create New Docker Rule

 

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.

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.