The Cybersecurity & Infrastructure Security Agency (CISA) is a U.S. federal agency that is responsible for strengthening cybersecurity across the government. The agency also provides resources for helping U.S. companies reducing cyber risk.
What is Zero Trust?
At a high level, Zero Trust is a cybersecurity methodology that assumes a breach can occur at any time. As such, each resource should have the least amount of privileges needed to perform their job and should be continuously authenticated to confirm authorization. The National Security Telecommunications Advisory Committee (NSTAC) describes Zero Trust as a cybersecurity strategy that treats every resource as untrusted. While most other security models use the location of an individual or device as a means to provide access, Zero Trust focuses on the data that is being accessed.
CISA Zero Trust Overview
CISA states that their maturity model is not the only way to accomplish Zero Trust. However, CISA’s model is clear, concise, possibly the easiest model to understand, and CISA has a strong reputation for solid recommendations. In CISA’s Zero Trust Maturity Model, there are five pillars, or categories, that contain controls for moving towards a Zero Trust Architecture. The five pillars are Identity, Devices, Networks, Applications & Workloads, and Data as shown in the image below.
Five pillars of CISA’s Zero Trust Maturity Model (Cybersecurity and Infrastructure Security Agency Cybersecurity Division, 2023)
There are a total of 36 security controls, or “functions” as CISA calls it, across all of the pillars. While there are unique security controls for each pillar, there are three control types that are within each pillar. These three control types that are cross-cutting through each pillar are Visibility and Analytics, Automation and Orchestration, and Governance. The cross-cutting controls can be used to coordinate implementation and interoperability of functions across the pillars.
The CISA Zero Trust model contains four maturity stages for each of the 36 security controls. Organizations start with the Traditional stage and move to Initial, Advanced, and finally Optimal. Each maturity stage provides an increasing level of protection and adoption complexity.
CISA Zero Trust 2.0 Maturity Stages
Implementation Challenges
Implementing Zero Trust is not a trivial task. There are 36 major functions that need to be optimized before achieving the highest maturity level. This is a process that will most likely take years for an organization to complete. Some of the challenges with implementing Zero Trust are:
Cost – An organization will probably need to purchase new security tools and hire additional staff to reach the higher levels of maturity. For example, an organization may have multi-factor authentication (MFA) with SMS (text message), but the more mature levels require “phishing-resistant MFA” such as Yubikeys or Feitian USB security keys. Purchasing the security keys and educating staff can be costly.
Time – It takes time to implement each of these security measures. This includes both implementation time and employee education time.
Process Change – There are numerous challenges to implementing new processes. Taking our MFA implementation example, an organization will need to change how they perform multi-factor authentication across the organization.
Legacy Systems – Many legacy systems were not designed with security in mind. These legacy systems may implicitly trust everyone, or have a single shared account.
CISA describes the Zero Trust implementation as a journey. Each stage of this journey requires more levels of effort while achieving greater protection.
CISA Zero Trust Maturity Model 2.0 Journey (Cybersecurity and Infrastructure Security Agency Cybersecurity Division, 2023)
Benefits of Zero Trust
Moving towards higher levels of maturity within Zero Trust have enormous security benefits which is why organizations strive to achieve this goal. At the Optimal maturity level, the risk of a security breach is minimized. Zero Trust can also help companies achieve compliance goals by moving well beyond the initial compliance requirements. There are also customer and business benefits as an organization with a higher level of security earns more trust from its customer base.
Changes from CISA Zero Trust v1.0 to v2.0
CISA has made a number changes from their Zero Trust maturity model 1.0 released in 2021 to version 2.0 that was released in April of 2023.
Color code chart for changes
Moving from Three to Four Maturity Stages
The largest change is moving from three to four maturity stages. As CISA states, the Zero Trust Maturity Model is a journey which will most likely take time to implement. Having more stages provides greater insight into an organization’s progress.
Changes to the Zero Trust Maturity Stages
Pillar Changes
There are still five pillars within the CISA Zero Trust Maturity Model 2.0, however the naming has changed slightly.
Changes to the Zero Trust Pillars
Security Functions within Pillars
The CISA Zero Trust Maturity Model has moved from 31 security controls (called “Functions” within the model) to 36 controls. The changes are listed below and grouped by each of the five pillars.
Velocity Can Help with the CISA Zero Trust Maturity Model Journey
At Stern Security, we have added the CISA Zero Trust Maturity Model into our Velocity platform. Any organization can easily map their Zero Trust journey within Velocity. Try Velocity for free today.
Velocity contains CISA’s Zero Trust Maturity Model
Conclusion
The 2.0 version of CISA’s Zero Trust Maturity Model is a well-organized and highly regarded framework to follow in order to achieve Zero Trust goals. Increasing an organization’s Zero Trust maturity is a journey that will take time and resources, but will greatly reduce cybersecurity risk. CISA’s model is a recommended approach for completing an organization’s Zero Trust goals.
Works Cited
Cybersecurity and Infrastructure Security Agency Cybersecurity Division. (2021, June). Zero Trust Maturity Model: Pre-decisional Draft Version 1.0. CISA.gov.
Cybersecurity and Infrastructure Security Agency Cybersecurity Division. (2023, April). Zero Trust Maturity Model: Version 2.0. CISA.gov.
Keeping up with Two-Factor Authentication Day (2/2/23), we decided to showcase some cybersecurity and compliance frameworks that recommend 2-factor authentication controls. The frameworks we reviewed include:
FFIEC CAT (The Federal Financial Institutions Examination Council Cybersecurity Assessment Tool)
PCI DSS (Payment Card Industry Data Security Standard) v3.2.1
PCI DSS (Payment Card Industry Data Security Standard) v4.0
CIS v8 (Center for Internet Security), NYDFS (New York State Department of Financial Services)
CISA (Cybersecurity & Infrastructure Security Agency) Shields Up 2022
ACET (Automated Cybersecurity Examination Tool) from the NCUA (National Credit Union Association)
NIST CSF (National Institute of Standards and Technology Cybersecurity Framework) 1.1
405(d) HICP (Health Industry Cybersecurity Practices).
Cybersecurity Framework References
The multi-factor authentication controls within these frameworks are listed in the chart below.
Framework
Reference
Control
FFIEC CAT
D3.PC.Am.B.9
Customer access to Internet-based products or services requires authentication controls (e.g., layered controls, multifactor) that are commensurate with the risk.
FFIEC CAT
D3.PC.Am.B.15
Remote access to critical systems by employees, contractors, and third parties uses encrypted connections and multifactor authentication.
FFIEC CAT
D3.PC.Am.Int.5
Multifactor authentication and/or layered controls have been implemented to secure all third-party access to the institution’s network and/or systems and applications.
FFIEC CAT
D3.PC.Am.Int.6
Multifactor authentication (e.g., tokens, digital certificates) techniques are used for employee access to high-risk systems as identified in the risk assessment(s). (*N/A if no high risk systems.)
CMMC
IA.L2-3.5.3
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
CMMC
MA.L2-3.7.5
Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
PCI DSS v3.2.1
8.3
Secure all individual non-console administrative access and all remote access to the CDE (Card Data Environment) using multi-factor authentication. Note: Multi-factor authentication requires that a minimum of two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered multi-factor authentication.
PCI DSS v3.2.1
8.3.1
Incorporate multi-factor authentication for all non-console access into the CDE (Card Data Environment) for personnel with administrative access.
PCI DSS v3.2.1
8.3.2
Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.
PCI DSS v4.0
8.4
Multi-factor authentication (MFA) is implemented to secure access into the CDE (Card Data Environment)
PCI DSS v4.0
8.4.1
MFA is implemented for all non-console access into the CDE for personnel with administrative access.
PCI DSS v4.0
8.4.2
MFA is implemented for all access into the CDE.
PCI DSS v4.0
8.4.3
MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE
PCI DSS v4.0
8.5
Multi-factor authentication (MFA) systems are configured to prevent misuse.
PCI DSS v4.0
8.5.1
MFA systems are implemented as follows: • The MFA system is not susceptible to replay attacks. • MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period. • At least two different types of authentication factors are used. • Success of all authentication factors is required before access is granted.
PCI DSS v4.0
8.6
Use of application and system accounts and associated authentication factors is strictly managed.
CIS v8
6.3
Require all externally-exposed enterprise or third-party applications to enforce MFA, where supported. Enforcing MFA through a directory service or SSO provider is a satisfactory implementation of this Safeguard.
CIS v8
6.4
Require MFA for Remote Network Access
CIS v8
6.5
Require MFA for all administrative access accounts, where supported, on all enterprise assets, whether managed on-site or through a third-party provider.
NYDFS
12a
Multi-factor authentication. Based on its risk assessment, each covered entity shall use effective controls, which may include multi-factor authentication or risk-based authentication, to protect against unauthorized access to nonpublic information or information systems.
NYDFS
12b
Multi-factor authentication shall be utilized for any individual accessing the covered entity’s internal networks from an external network, unless the covered entity’s CISO has approved in writing the use of reasonably equivalent or more secure access controls.
CISA Shields Up 2022
1.1
Validate that all remote access to the organization’s network and privileged or administrative access requires multi-factor authentication.
ACET
232
Remote access to critical systems by employees, contractors, and third parties uses encrypted connections and multifactor authentication.
ACET
245
Multifactor authentication and/or layered controls have been implemented to secure all third-party access to the institution’s network and/or systems and applications.
ACET
246
Multifactor authentication (e.g., tokens, digital certificates) techniques are used for employee access to high-risk systems as identified in the risk assessment(s).
NIST CSF 1.1
PR.AC-7
Users, devices, and other assets are authenticated (e.g., single-factor, multi- factor) commensurate with the risk of the transaction (e.g., individuals’ security and privacy risks and other organizational risks)
405(d) HICP
2.S.A.6
For devices that are accessed off site, leverage technologies that use multi-factor authentication before permitting users to access data or applications on the device. Logins that use only a username and password are often compromised through phishing e-mails.
405(d) HICP
3.M.D.1
Virtual Private Networks (VPNs) should be configured to limit user access based on role-based access control (RBAC) or ABAC rules and to enable MFA.
405(d) HICP
3.M.D.2
These [Virtual Desktop Environments] are environments where virtual terminal sessions can be exposed to remote access, allowing your employees to work remotely. Although highly useful for workforce flexibility, virtual desktop environments systems can be compromised easily if they lack MFA.
405(d) HICP
9.M.C.3
If remote access is required to manage medical devices, MFA capabilities should be deployed, with HDO acceptance of the system access mode to be used. Depending on the deployment scenario, the device manufacturer may be required to support remote access capabilities. Otherwise, such capabilities should be deployed on a separate component of your existing MFA system to limit exposure if the MFA system is compromised.
If you want to learn more about 2-factor authentication, please check out our article at Stern Security. To ensure that you’re adhering to all of your cybersecurity controls including 2-factor authentication, use Velocity. You can measure your baseline security for free with Velocity today. Secure the Planet!
405(d) Health Industry Cybersecurity Practices (HICP) is a healthcare cybersecurity framework created out of a congressional mandate from the Cybersecurity Act of 2015. Section 405(d) of this mandate has a goal to strengthen the cybersecurity posture of healthcare and public health sector. A collective called the 405(d) Task Force was formed from both public and private sectors. This task force contains members of the U.S. Health and Human Services, over 200 healthcare and cybersecurity experts, and the Health Sector Coordinating Council. Their deliverable was the 405(d) Health Industry Cybersecurity Practices (HICP): Managing Threats and Protecting Patients. This framework contains 326 cybersecurity controls for organizations within the healthcare industry.
What is a Cybersecurity Framework?
A Cybersecurity framework is a collection of controls that companies can put in place to reduce the risk of a cyber-attack. An example control could be “Enable Multi-Factor Authentication (MFA) for all Remote Access”.
What Size Organizations Use 405(d) HICP?
Any size organization can use the 405(d) HICP guidance. The framework is divided into three sections: Small Organizations, Medium Organizations, and Large Organizations. The framework recommends that healthcare organizations follow the controls specific to their size. One may ask how the size of an organization is determined. The framework contains a chart for organizations to use to determine their size. This chart is shown below.
Organization sizing guide (Department of Health and Human Services)
Is 405(d) HICP Only for Healthcare?
Most of the controls within 405(d) HICP can be used by organizations in any industry. However, there is one section of the framework, Section 9, which contains 25 controls for Medical Devices. This section simply would not apply to non-Healthcare industries.
How Can I Follow the 405(d) Guidance?
The 405(d) HICP Framework can be found as a detailed PDF or a basic spreadsheet on the Health and Human Services website: https://405d.hhs.gov/protect/hicp. Unfortunately, working through the PDF or spreadsheet is not ideal because it takes considerable manual effort to create graphs to show progress and program maturity. Thankfully, Stern Security has built the 405(d) framework into Velocity. Within Velocity, the 405(d) framework is easy to use, has a clean interface, contains graphs that depicts an organizations maturity, and has reports for download. Additionally, the controls for small organizations are completely FREE. Any organization can quickly sign up for a free Velocity account and start using the 405(d) HICP framework today.
Works Cited
Department of Health and Human Services. (n.d.). Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients. Retrieved from HHS 405(d) Aligning Health Care Industry Security Approaches: https://405d.hhs.gov/Documents/HICP-Main-508.pdf
On November 4, 2021, to safeguard sensitive national security information, the Department of Defense (DoD) launched Cybersecurity Maturity Model Certification (CMMC) 2.0, a comprehensive framework to protect the defense industrial base (DIB) from increasingly frequent and complex cyberattacks. With its streamlined requirements, CMMC 2.0 was created to: • Cut red tape for small and medium sized businesses • Set priorities for protecting DoD information • Reinforce cooperation between the DoD and industry in addressing evolving cyber threats. The Department posted the CMMC 2.0 model for Levels 1 and 2 in December with their associated Assessment Guides and scoping guidance. Level 3 information will be posted as it becomes available (currently still under development).
What is CMMC Intended to Protect?
The CMMC model is designed to protect Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) that is shared with contractors and subcontractors of the Department through acquisition programs.
What is FCI?
In alignment with section 4.1901 of the Federal Acquisition Regulation (FAR), FCI is defined as information, not intended for public release, that is provided by or generated for the Government under a contract to develop or deliver a product or service to the Government, but not including information provided by the Government to the public (such as that on public websites) or simple transactional information, such as that necessary to process payments.
What is CUI?
CUI is information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls. The CUI Registry provides information on specific CUI categories and subcategories and can be accessed through the National Archives and DoD websites.
Who Must Comply?
The CMMC program includes cyber protection standards for companies in the defense industrial base. By incorporating cybersecurity standards into acquisition programs, CMMC provides the Department assurance that contractors and subcontractors are meeting DoD’s cybersecurity requirements.
By When?
The changes reflected in CMMC 2.0 will be implemented through the rulemaking process. Companies will be required to comply once the forthcoming rules go into effect. The Department intends to pursue formal rulemaking both in Part 32 of the Code of Federal Regulations (C.F.R.) as well as in the Defense Federal Acquisition Regulation Supplement (DFARS) in Part 48 of the C.F.R. Both rules will have a public comment period. Stakeholder input is critical to meeting the objectives of the CMMC program, and the Department will actively seek opportunities to engage stakeholders as it drives towards full implementation.
Stern Security’s Security & Compliance Architect has become a Registered Practitioner (RP) through the CMMC Accreditation Body (CMMC-AB) and we’ve added both CMMC 2.0 Level 1 and Level 2 to Velocity. We’ve made it easy to self-assess for the CMMC 2.0, allowing our customers to prepare for the final versions of this framework. Velocity provides easy-to-understand examples combined with detailed explanations for each control to help our customers simplify their compliance efforts.
