As part of their white paper on Zero Trust SP-800-207, NIST identified Seven Tenets that form the foundation of Zero Trust. The Zero Trust Workgroup at CMS has applied these tenets to CMS IT. CMS has many initiatives that support Zero Trust architecture, so engaging with those early can set your project up for a more mature Zero Trust architecture in the future and increase security now.

1. All data sources and computing services are considered resources

All data sources and computing services that process CMS data are considered resources and should have defined controls and zero trust solutions governing access to them. Data sources include data repositories, file shares, and databases, while computing services include servers, EC2 instances, containers, and AWS lambda functions.

2. All communication is secured regardless of network location

Traffic flowing between resources must be secured with appropriate encryption and authentication mechanisms as close to the originating resource as possible -- whether both resources are in the same network or if the data has to transit to another network.  Encryption is not only for privacy but also for protection against modification in transit.

The OIT memo "CMS Strategy for Encrypting Sensitive Information" mandates CMS is required to encrypt sensitive information at rest and in transit on all CMS Systems that store process, or transmit such information, especially High Value Assets (HVA), Mission Essential Functions, and Sensitive PII systems.  The CMS Enterprise Data Encryption Initiative has been working on helping ISSOs get their data encrypted since 2021.

3. Access to individual enterprise resources is granted on a per-session basis

Trust in the user or developer is evaluated before the access is granted to a specific resource (e.g., authentication), and access should also be granted with the least privileges needed to complete the task (e.g., authorization).  Authenticated sessions should be time-bound, with a session lasting less than 24 hours.  The length of a session can vary based on the sensitivity of the data as long as it is finite.  Additionally, authentication and authorization to one resource should not automatically grant access to a different resource.

Use existing identity management systems such as IDM to the greatest extent possible to perform authentication and authorization -- avoid creating new ones.  There are systems available for developers and users alike.   Developers should be granted the least amount of privileges to the resource as possible; CloudTamer, now called Kion, for CMSCloud is a great way to do that.

4. Access to resources is determined by dynamic policy

Mature Zero Trust architectures strive to have access policies that take input from external systems, such as the asset they are using or the user's location, to determine the current access level for the user.  For example, some government systems cannot be accessed outside the United States.  This is often referred to as risk-based or attribute-based authentication.  

While attribute-based authentication is the goal of Zero Trust, the technology is still fairly new.  In the future, the Zero Trust Workgroup plans to provide a way for ADOs to do attribute-based authentication, but this is likely a ways off for widespread use. 

5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets

The enterprise does not inherently trust any asset, whether CMS owns the asset or not.  CMS monitors the security posture of every asset, and uses that information when that asset requests access to resources. CMS already employs a dynamic policy for Government Furnished Laptops attempting to access CMSNet. Devices must have a device certificate, certain security software, and have the current security patches installed before it may join the network, and devices that do not meet this are sent to a different network for remediation.

Virtual Machines (VMs) and containers are also assets and should be treated in similar ways. These operating systems must be patched and vulnerability scanned just like physical servers would -- VMs and containers with known vulnerabilities should not be deployed to production. CMSCloud offers a Gold Image for AWS and MAG to help ADOs deploy VMs with the latest patches. ISSOs are encouraged to have ADOs take advantage of these options and existing vulnerability scanning tools.

6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed

Access to resources is subject to a constant cycle of scanning for threats, evaluating trust, and obtaining access. Continuous monitoring with possible reauthentication and reauthorization occurs throughout a user transaction and happens as close to the application as possible.

ISSOs should work with the team to determine reasonable user login timeouts based on ARS 5.1 requirements and customer experience.  This includes APIs as well as web applications.

7. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve its security posture

Agencies should maintain an ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions.  This includes continuous visibility into the actions of users, applications, and devices through a centralized log data collection. CMS does this in part through the Continuous Diagnostics & Mitigation (CDM) program run by ISPG. CMS uses asset inventories and vulnerability management scanning to keep tabs on both resources that employees use (e.g. laptops) and the applications and infrastructure they use. 

ADOs can contribute by participating in the CDM program as it becomes available for their infrastructure. ADOs also need to understand the state of their infrastructure, as well as provide those logs and context to central security teams (follow the guidelines in ARS 5.0).  Strive to know "who did what when" about both your developers and your users.