Executive Order that requires the continuous verification of system users to promote system security
The history of Zero Trust
In May 2021, the Biden Administration issued Executive Order (EO) 14028, charging federal agencies with the task of modernizing and enhancing cybersecurity. Executive Order 14028 was quickly followed by guidance from the Office of Management and Budget (M-22-09) recommending the introduction of Zero Trust security practices and offering specific steps agencies needed to take to implement them. So what is Zero Trust (ZT), and how will these important changes impact your daily work?
What is Zero Trust?
Zero Trust is a security model that is built on continuous validation at every stage of digital interaction. The Zero Trust (ZT) security model, also known as Zero Trust Architecture (ZTA), maintains that no user or application should be trusted by default. As a result, organizations that implement a Zero Trust model move from checking permissions only at initial sign-on to continuously checking permissions as users or devices move through a system. This constant validation provides enhanced security for systems, devices, and users. Below are the associated concepts and policies that go hand-in-hand with the Zero Trust model.
Zero Trust policy: least privilege
The policy of least privilege is associated with the Zero Trust model and is designed to give users the least amount of access to a system or device that is required to complete a task. For example, if a system administrator wants to add new users to a given system, only that single permission is granted to complete that task. If the same system administrator wants to perform a different task, like deleting inactive users, their permissions will need to be reevaluated. In this scenario, the extra level of authentication prevents a malicious user from being able to casually use sensitive privileges like deleting users; it also prevents accidents from happening through trusted user error.
Zero Trust policy: assuming compromise
Assuming compromise means just what it says: as part of the Zero Trust model, we assume that our systems have been compromised by threats. To increase our overall security posture, we design our systems to limit access to data and networks. Limitations can look like restricted connections between networks or different applications. These limitations can prevent malicious users from accessing sensitive data or data that lives on unrelated networks or applications.
As CMS moves toward a Zero Trust model, you may notice some changes in how you sign in to devices and systems at work. This isn’t because we don’t trust you – we just want to be sure that the person logging in is you so that you can keep doing the great work you do.
Zero Trust at CMS
CMS’s transition to Zero Trust is a journey. It will involve a series of small adjustments over time that will allow our agency to transition from a traditional perimeter-based security model to a system of continuous authorization, authentication, and validation. You may have already noticed some of the important changes that have been implemented to support Zero Trust at CMS including:
- The introduction of CMS Cloud
- Our move to the Zscaler integrated platform
- The use of PIV cards for user authentication
There is no single tool that CMS can deploy to instantly implement Zero Trust across all systems; different system architectures will be necessary for different environments. To create those custom architectures, CMS is using the Cybersecurity and Infrastructure Security Agency (CISA) Zero Trust Maturity Model.
CISA Zero Trust Maturity Model
The CISA Zero Trust Maturity Model is a roadmap designed to transition federal agencies to Zero Trust by assessing their current security stance and recommending specific changes that will improve security moving forward. The model assesses system components, referred to as “pillars”, as well as general details regarding system visibility and analytics (how information is collected), automation and orchestration (how security is created through automated processes), and governance (the policies that guide the work). The pillars being assessed for all CMS systems are:
- Identity – An attribute or set of attributes that describe a CMS user.
- Devices – A hardware asset that can be connected to a network, such as a laptop or mobile device provided by CMS. Devices can also include virtual machines and containers.
- Networks – Internal CMS networks, data centers, and internet-based networks.
- Applications and workloads – CMS systems, computer programs, and services that execute on-premise, as well as in a cloud environment.
- Data – Information that CMS collects, from documents to information collected from the public to fulfill our mission.
These are the stages identified in the CISA Zero Trust Maturity Model that will help CMS track progress towards full adoption and implementation of Zero Trust standards.
The traditional level of maturity is marked by manually configured lifecycles (i.e., from establishment to decommissioning) and assignments of attributes (security and logging); static security policies and solutions that address one pillar at a time with discrete dependencies on external systems; manual response and mitigation deployment; least privilege established only at provisioning; siloed pillars of policy enforcement; and limited correlation of dependencies, logs, and telemetry.
At the level described as initial, increased maturity is demonstrated by starting automation of attribute assignment and configuration of lifecycles, policy decisions, and enforcement, and initial some responsive changes to least privilege after provisioning; cross-pillar solutions with integration of external systems; and aggregated visibility for internal systems.
At the advanced level of maturity, wherever applicable, automated controls for lifecycle and assignment of configurations and policies with cross-pillar coordination; response to pre-defined mitigations; changes to least privilege based on risk and posture assessments; policy enforcement integrated across pillars; and centralized visibility and identity control building toward enterprise-wide awareness (including externally hosted resources).
The optimal level of maturity is demonstrated by fully automated, just-in-time lifecycles and assignments of attributes to assets and resources that self-report with dynamic policies based on automated/observed triggers; dynamic least privilege access (just-enough and within thresholds) for assets and their respective dependencies enterprise-wide; cross-pillar interoperability with continuous monitoring; and centralized visibility with comprehensive situational awareness.
As our Zero Trust rollout continues, System Owners will work with their teams to evaluate their desired level of maturity. While Optimal maturity is the goal for every system, not all systems will be required to achieve it. Most systems will be required to achieve Advanced maturity, and many systems will be able to use CMS-wide tooling to make changes as your specific system requirements are defined.
In general, this process will start with homogeneous cloud environments that use the same software and devices. We will then move on to custom environments and systems until all CMS systems have been properly evaluated.
Zero Trust and compliance
While Zero Trust is not a compliance framework, its principles complement the existing compliance frameworks at CMS like Acceptable Risk Safeguards 5.0.
ARS 5.0 already supports many of the best practices offered by Zero Trust, such as the least privilege policy for certain levels of systems (e.g. High and Moderate) and the assumed compromise policy. As all CMS systems move to Zero Trust Architecture, System Owners are encouraged to add their own flair and implement tools and resources that will keep their systems compliant and push them closer to Optimal maturity. As specific implementation expectations are developed, they will be incorporated into future versions of ARS.
ISSOs and others directly involved in the compliance process for CMS systems should watch for news and updates from ISPG for information related to Zero Trust implementation and its impact on compliance activities.
How will Zero Trust impact me?
Many of the Zero Trust improvements implemented by CMS will be invisible to users. You may see more instances where you’re asked to provide two-factor authentication when accessing websites and apps. Since you’re using your work computer, your device will share information with CMS about the status of your system. For example, our networks will know if your computer patches are up to date and if there is a valid device certificate. This information not only keeps your computer and CMS systems safe and secure, but it also increases the amount of trust that CMS has that the person logging in is you.
Throughout the Zero Trust rollout at CMS, we will introduce new tools that will streamline existing processes while also increasing security. Members of OIT or others who run IT infrastructure at CMS will see the biggest changes, and overall, it should improve security while reducing burdens.
Application Owners will also see changes as the environments they are in have more ZT features available, such as additional multi-factor authentication options for users or increased network encryption. These changes will make applications and systems more resilient to malicious attacks.
Zero Trust FAQs
Where can I read about Zero Trust features, functionality, or offerings applicable to CMS?
CyberGeek is a great place to get started reading more about how Zero Trust will apply to CMS. Most of what we store here will be overviews, though, so as we have more features and functionality available, we will need to move that to internal knowledge repositories.
To the extent possible, we will keep zero trust information near where you will use it. If you are building your applications on CMS Cloud, you can find more specific information on cloud.cms.gov. We also have spaces on the internal CODA site and Slack for more information. We also focus on keeping the ISSO community informed through the monthly C3F, announcements in Slack, and the ISSO Journal.
What is changing for CMS?
Right now? Not much. Over time we will roll out more options for Multi-factor authentication, access control for data, and micro-segmentation within subnets and applications. A lot of the changes are going to be on a case-by-case basis, though, so it’s hard to say if there is something everyone is going to have to change.
When will we get information on what we need to do on an ADO level? What other processes can we pilot/test drive for you?
The Zero Trust Maturity Data Call for systems hosted in AWS for CMS Cloud is scheduled to launch in January 2023. This will help us identify areas that we can assist teams in maturity, their zero trust functionality. One area we expect to address first is log analysis for identifying PII such as SSNs or Medicare patient numbers (HICNs, MBIs) in Splunk and other logging systems that are not certified to hold PII for CMS.
How will Zero Trust affect making information accessible to CMS staff and CMS contractors?
Ideally, we will make it easier to make data and information accessible to CMS staff, contractors, and consultants. The increased use of Attribute-based access control through various systems at our disposal can allow us to adapt what data is accessible by authorized persons based on other factors like what team they are on, what role they have, and if they are using GFE that is up-to-date. These changes will be made in upstream systems like IDM/Okta and Kion (nee CloudTamer) so that they can be used easily by different teams.
The Maturity Framework Evaluation appears to be scoring questions for an entire team at once: 1/2/3 points based on the status of all the systems. But it’s rare to be equally mature across all systems: perhaps user-facing applications are integrated with the agency’s external identity management system, but a tool for team administrators like CI/CD is not. Wouldn’t you get a better view of the team’s maturity by asking separately about those systems?
That is a great observation and one that we arrived at when we were adapting the CISA Zero Trust Maturity Model to CMS. CISA’s original only had one function listed for Authentication, which was pretty general. When reviewing the CISA Model, we decided to split the authentication questions into three (3) parts:
- ADO staff/developers
- Interactive users of websites
- API users
We recognize that the technology needed for each of those is different and likely matures at different levels. It is a tough balance being granular enough to tease out distinctions like different kinds of users, but not too granular that we have to ask 200 questions to judge maturity level.
How can my system get a Zero Trust evaluation?
Reach out with your request to the ISPG Zero Trust Team. Include information about your system:
- Name and Acronym
- Environment it runs in (e.g. AWS for CMS Cloud, Azure for CMS Cloud, Ashburn, etc.)
- Names and email addresses of other people to be involved
Zero Trust Ambassador Program
The Zero Trust Ambassador Program is for ISSOs, Security Engineers, Network Engineers, and Application developers who work on systems at CMS. It gives you access to additional Zero Trust content related to CMS environments, so you can:
- Learn more about Zero Trust security
- Test new Zero Trust recommendations
- Share Zero Trust practices with your team
Learn more about the Zero Trust Ambassador Program here.