Preventing Cyber Attacks with Trusted Image Registries
- August 24, 2021
Recently, Bryan Langston, Senior Solutions Engineer at Mirantis, presented at MediaOps' virtual event Cloud Native Days, highlighting the latest cyber attacks and explaining best practices for protecting your organization from these types of attacks through the use of image registries.
Below you will find the recording as well as a transcript to help you follow along as Bryan takes you through the ins-and-outs of securing your applications across your organization's software supply chain.
My comments today aren't going to say that if you do the things I discuss, you won't become a victim of a similar attack. I want to mention SolarWinds only to help illustrate the importance of certain key attributes and importance of the supply chain. One big takeaway or realization about the recent attacks is that many US supply chains are vulnerable, for various reasons, and these vulnerabilities cause serious disruptions to many aspects of daily life. Protecting them ensures continuity of service, economic activity, and other benefits.
So, the anatomy of a SolarWinds attack. This is something by now that you've most likely heard of, it was a supply chain attack, and what that means is the attack was targeted using a third-party, and in this case SolarWinds. The actors infiltrated SolarWinds supply chain and inserted code that, once deployed by SolarWinds customers, opened up back doors. So given that the US Cyber Command was blindsided by the attack, it's worth asking yourself: how your own organization would fare? What mechanisms are in place to mitigate impact of any attack, not just one with level of sophistication of SolarWinds.
The key difference is that you're starting with an assumption that a breach has already occurred. So if you assume you’ve already been compromised you probably ask yourself a different set of questions compared to the other strategies. What's your next move? Do you implement more monitoring? Would you use your tooling in a different way? Ideally though, a combination of all three strategies have to be used.
At Mirantis, one of our focus areas is helping our customers ship code faster, and one of the frameworks for doing that is what we call a secure software supply chain. What I'm showing here is a reference architecture for it that reflects our product portfolio and the integrations with other third party products. One of the ideas behind a secure software supply chain is the fact that you have various segments within the supply chain that allow you to optimize the process and secure the application as it progresses along the supply chain.
Mirantis Secure Registry is one of the components of the Mirantis Cloud Native Platform, and these five pillars are required, in my opinion again, to fully maximize the value that an image registry can bring to your secure supply chain. You have to be doing at least these things, and the first one is access control. You have to be able to have full transparency to who is doing what to which objects in your supply chain, who is signing, who is promoting, who is sharing what Images.
Image scanning is also a must. Mirantis Secure Registry supports image scanning at the binary level and then correlates output with a regularly updated CDE vulnerability database. Image signing is the 3rd pillar, that's about digitally signing and verifying the contents and publisher of images. Developers and CI tools can also apply signatures, so that downstream users and automation tools can verify image authenticity before running. The fourth security pillar has to do with lifecycle management of the container. Container images may be lightweight, but that doesn't mean you want to store every image your team or CI tool creates forever. So in order to keep the newest and hopefully most updated images, you'll want to automatically clean up images based on policy controls, like the date of the last update or number of recent images you want to keep.
Now, policy management helps you streamline the development and delivery pipeline and enforce security controls, and there's two parts to policy management. One, is the set of policies that are provided out-of-the-box. These have to do with things like only promoting images that have been scanned in the past 30 days, or that have been signed or approved before deployment, and there are a number of predefined policies with Mirantis Secure Registry. The second part of policy management has to do with the custom policies that your team needs to write, that reflects your organization’s custom, unique security requirements. This is where you'll have to work closely with your compliance team to understand what those requirements are and how they'll be implemented in your secure supply chain. And I can't emphasize that enough. A lot of companies and organizations really struggle with that, bringing in the compliance teams and having open, effective dialog with engineering teams.
Here is one really good reason for working closely with compliance teams. Earlier this year, around March, late March, FedRAMP came out with six vulnerability scanning requirements for containers. They're all listed here on this slide. I won't go into heavy detail on each one, but these are all six, again, mandates for organizations that are required to comply with FedRAMP, but I would go one step further and say that any production container operation must include these as well, it doesn't matter if you're FedRAMP use case or not. These are industry best practices. This is table stakes. You've got to be doing this at least and more, if you want to have good control over your secure Kubernetes environment. So again, these are mandates. They have to be implemented by September of 2021, that's how critical these steps are, and Mirantis Secure Registry supports all of these requirements. And again, going back to a statement I made at the beginning, just by implementing these controls does not necessarily mean that you will avoid similar kinds of SolarWinds attacks. This is just one step of many to help mitigate that risk.
The Compliance team needs to help influence what the DevOps and DevSecOps teams are putting into the orchestration tooling, that includes the container registry. So assessing image registries, assessments don't come in a “one-size-fits-all” package, they can take multiple forms. What you have to do first is decide which settings and configurations you'll be audited against, and then figure out what the best way is to collect the data for that.
Unfortunately, collection is likely to be manual. In many cases, scripts could be written to query your registry for the data you're looking for. To help support secured by default mindset we have at Mirantis, our secure registry product is implementing a secure read only API that helps enable the automated collection of security related settings, to help facilitate these registry assessments. Regardless of your estimates and data collection methodologies, your registry assessment will require your DevSecOps teams working with the Security Project Management office and compliance teams for proper implementation.
So I hope that helps you and your organizations to help achieve a greater level of security. Thank you.
Below you will find the recording as well as a transcript to help you follow along as Bryan takes you through the ins-and-outs of securing your applications across your organization's software supply chain.
Transcript
Hi, my name is Bryan Langston. I'm a Senior Solutions Engineer at Mirantis, and I lead security initiatives with our most security conscious customers, advising on security and compliance strategies, methodologies, and tooling. Today, I'll be focusing on a topic that's been in the news a lot lately, which is cyber attacks.Cyber Security Overview
My objective for today is to discuss how image registries, specifically, can help avoid cyber attacks and in doing so, I want to highlight a few characteristics of some of the more recent publicized attacks, like SolarWinds and Ransomware, and what some strategies are to prevent similar attacks. I'll talk about the concept of a secure software supply chain and the role image registries have in them.My comments today aren't going to say that if you do the things I discuss, you won't become a victim of a similar attack. I want to mention SolarWinds only to help illustrate the importance of certain key attributes and importance of the supply chain. One big takeaway or realization about the recent attacks is that many US supply chains are vulnerable, for various reasons, and these vulnerabilities cause serious disruptions to many aspects of daily life. Protecting them ensures continuity of service, economic activity, and other benefits.
So, the anatomy of a SolarWinds attack. This is something by now that you've most likely heard of, it was a supply chain attack, and what that means is the attack was targeted using a third-party, and in this case SolarWinds. The actors infiltrated SolarWinds supply chain and inserted code that, once deployed by SolarWinds customers, opened up back doors. So given that the US Cyber Command was blindsided by the attack, it's worth asking yourself: how your own organization would fare? What mechanisms are in place to mitigate impact of any attack, not just one with level of sophistication of SolarWinds.
Risk Mitigation Strategies
Companies typically have two risk mitigation strategies and one is preventive in nature. This is where you proactively plan for known risks, you protect known attack vectors, and anticipate what methodologies might be used against you. In a reaction strategy, you're responding to a detected threat, and your response might be in the form of a new tool, maybe a new process, a feature, or a setting. More frequently though, a mitigation strategy is being used, the 3rd one here.The key difference is that you're starting with an assumption that a breach has already occurred. So if you assume you’ve already been compromised you probably ask yourself a different set of questions compared to the other strategies. What's your next move? Do you implement more monitoring? Would you use your tooling in a different way? Ideally though, a combination of all three strategies have to be used.
At Mirantis, one of our focus areas is helping our customers ship code faster, and one of the frameworks for doing that is what we call a secure software supply chain. What I'm showing here is a reference architecture for it that reflects our product portfolio and the integrations with other third party products. One of the ideas behind a secure software supply chain is the fact that you have various segments within the supply chain that allow you to optimize the process and secure the application as it progresses along the supply chain.
Common Security "Tellers"
Various gates are defined but help ensure that the application doesn't progress, or ultimately get deployed, unless all conditions are met. One of the key components to the supply chain is the container image registry. I've outlined five, what I view, are five security tellers.Mirantis Secure Registry is one of the components of the Mirantis Cloud Native Platform, and these five pillars are required, in my opinion again, to fully maximize the value that an image registry can bring to your secure supply chain. You have to be doing at least these things, and the first one is access control. You have to be able to have full transparency to who is doing what to which objects in your supply chain, who is signing, who is promoting, who is sharing what Images.
Image scanning is also a must. Mirantis Secure Registry supports image scanning at the binary level and then correlates output with a regularly updated CDE vulnerability database. Image signing is the 3rd pillar, that's about digitally signing and verifying the contents and publisher of images. Developers and CI tools can also apply signatures, so that downstream users and automation tools can verify image authenticity before running. The fourth security pillar has to do with lifecycle management of the container. Container images may be lightweight, but that doesn't mean you want to store every image your team or CI tool creates forever. So in order to keep the newest and hopefully most updated images, you'll want to automatically clean up images based on policy controls, like the date of the last update or number of recent images you want to keep.
Now, policy management helps you streamline the development and delivery pipeline and enforce security controls, and there's two parts to policy management. One, is the set of policies that are provided out-of-the-box. These have to do with things like only promoting images that have been scanned in the past 30 days, or that have been signed or approved before deployment, and there are a number of predefined policies with Mirantis Secure Registry. The second part of policy management has to do with the custom policies that your team needs to write, that reflects your organization’s custom, unique security requirements. This is where you'll have to work closely with your compliance team to understand what those requirements are and how they'll be implemented in your secure supply chain. And I can't emphasize that enough. A lot of companies and organizations really struggle with that, bringing in the compliance teams and having open, effective dialog with engineering teams.
Here is one really good reason for working closely with compliance teams. Earlier this year, around March, late March, FedRAMP came out with six vulnerability scanning requirements for containers. They're all listed here on this slide. I won't go into heavy detail on each one, but these are all six, again, mandates for organizations that are required to comply with FedRAMP, but I would go one step further and say that any production container operation must include these as well, it doesn't matter if you're FedRAMP use case or not. These are industry best practices. This is table stakes. You've got to be doing this at least and more, if you want to have good control over your secure Kubernetes environment. So again, these are mandates. They have to be implemented by September of 2021, that's how critical these steps are, and Mirantis Secure Registry supports all of these requirements. And again, going back to a statement I made at the beginning, just by implementing these controls does not necessarily mean that you will avoid similar kinds of SolarWinds attacks. This is just one step of many to help mitigate that risk.
DevSecOps & Compliance
DevSecOps and Compliance. A lot of companies I've consulted with struggled when it comes to the security and compliance culture within an organization that's evolving towards a cloud native future. The struggle comes in the way of development and engineering teams working independently from compliance teams, and these days, DevOps and DevSecOps teams are focused pretty much on the traditional software development life cycle. This is about building and deploying an application. DevSecOps teams are more frequently being used to represent the security best practices, but really from a perspective of verifying that the deployment of an application follows industry best practices. Compliance, on the other hand, has to do with the compliance framework. It is about regulations. It's about risk management, protecting the company by ensuring that the right safeguards are properly defined, implemented, assessed and verified. They're about checklists, making sure that processes and procedures are in place and making sure that methodologies exist and that they're being applied to enforce the myriad security requirements that must be satisfied. But these two teams, DevOps, DevSecOps and the compliance team counterparts, they have to work together.The Compliance team needs to help influence what the DevOps and DevSecOps teams are putting into the orchestration tooling, that includes the container registry. So assessing image registries, assessments don't come in a “one-size-fits-all” package, they can take multiple forms. What you have to do first is decide which settings and configurations you'll be audited against, and then figure out what the best way is to collect the data for that.
Unfortunately, collection is likely to be manual. In many cases, scripts could be written to query your registry for the data you're looking for. To help support secured by default mindset we have at Mirantis, our secure registry product is implementing a secure read only API that helps enable the automated collection of security related settings, to help facilitate these registry assessments. Regardless of your estimates and data collection methodologies, your registry assessment will require your DevSecOps teams working with the Security Project Management office and compliance teams for proper implementation.
Conclusion
So, in summary, just as we are seeing the vulnerabilities of supply chains in the United States with recent Ransomware attacks, your software development supply chain is equally a critical component to your company's success and must be adequately protected. Securing your image registry won't solve all your problems, obviously, but when implemented with multiple risk managers strategies in mind, again proactive, reactive and mitigation, and then deeply integrated with your orchestration pipeline, you can achieve a secure software supply chain concept.So I hope that helps you and your organizations to help achieve a greater level of security. Thank you.
