Skip to main content

Registry Risks

January 21, 2020

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

By: Dan Kiraly

Senior Research Analyst

See More

Related Blogs

December 10, 2019

Your Risk is Shifting to Places You Can’t See

CISOs and their teams face a daunting task fending off cybersecurity threats, which at present number in the hundreds of millions. But security leads ...

See Details

January 06, 2020

Image Risks

Part Three of our series explores what native AWS tools and third-party solutions are available to address the risks identified in the NIST SP 800-190...

See Details

January 02, 2020

Extending the Hybrid Cloud Lab

Part 2 in the Gaining Visibility into NIST SP 800-190 series is designed for security practitioners and others starting down the path of understanding...

See Details

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.


Privacy Policy

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.

Subscribe

Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay Connected

Find cybersecurity Events in your area.