| Trustmark Definition Name | Version |
|---|---|
|
The requirements for enrollment codes to only be available for certain periods of time depending on the transmission media of those enrollment codes.
|
3.0 |
|
The requirements for a CSP to send notification of enrollment to a confirmed address of record.
|
3.0 |
|
The requirements for a CSP to send notification of enrollment to an address of record differing from the one to which an enrollment code was sent.
|
3.0 |
|
The requirements for vertting an applicants address when performing supervised identity proofing.
|
3.0 |
|
Requirements for address confirmation for high assurance.
|
3.0 |
|
The requirements for vetting an applicants address when performing unsupervised identity proofing.
|
3.0 |
|
The requirements for enrollment codes to be reset on first use if they are also a factor in multi-factor authentication.
|
3.0 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice RV.3: Analysis of Vulnerabilities to Identify Their Root Causes. Requires an organization to help reduce the frequency of vulnerabilities in the future.
|
1.1 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice PS.3: Archival and Protection of Each Software Release. Requires an organization to preserve software releases in order to help identify, analyze, and eliminate vulnerabilities discovered in the software after release.
|
1.1 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice RV.2: Assessment, Prioritization, and Remediation of Vulnerabilities. Requires an organization to help ensure that vulnerabilities are remediated in accordance with risk to reduce the window of opportunity for attackers.
|
1.1 |
|
Specifies requirements in accordance with the DHS CISA Secure-by-Design Pledge, published by the U.S. Dept of Homeland Security (DHS) Cybersecurity and Infrastructure Agency (CISA). Requires an organization to enable automatic installation of software patches by default where appropriate, across all of its product and service offerings.
|
1.0 |
|
Specifies requirements in accordance with the DHS CISA Secure-by-Design Pledge, published by the U.S. Dept of Homeland Security (DHS) Cybersecurity and Infrastructure Agency (CISA). Requires an organization to provide baseline logging for configuration changes, identity, network, and data access events, across all of its product and service offerings.
|
1.0 |
|
Specifies requirements in accordance with the DHS CISA Secure-by-Design Pledge, published by the U.S. Dept of Homeland Security (DHS) Cybersecurity and Infrastructure Agency (CISA). Requires an organization to clearly communicate end-of-life (EOL) timelines and offer transition support or guidance for unsupported products, across all of its product and service offerings.
|
1.0 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice PW.6: Configuration of Compilation, Interpreter, and Build Processes to Improve Executable Security. Requires an organization to decrease the number of security vulnerabilities in the software and reduce costs by eliminating vulnerabilities before testing occurs.
|
1.1 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice PW.9: Configuration of Software to Have Secure Settings by Default. Requires an organization to help improve the security of the software at the time of installation to reduce the likelihood of the software being deployed with weak security settings, putting it at greater risk of compromise.
|
1.1 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice PW.5: Creation of Source Code via Adherence to Secure Coding Practices. Requires an organization to decrease the number of security vulnerabilities in the software, and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria.
|
1.1 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice PO.4: Definition and Use of Criteria for SDLC Software Security Checks. Requires an organization to help ensure that the software resulting from the SDLC meets the organization's expectations by defining and using criteria for checking the software's security during development.
|
1.1 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice PO.1: Definition of Security Requirements for Software Development. Requires an organization to ensure that security requirements for software development are known at all times so that they can be taken into account throughout the SDLC and duplication of effort can be minimized because the requirements information can be collected once and shared. This includes requirements from internal sources (e.g., the organization's policies, business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations).
|
1.1 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice PW.1: Design of Software to Meet Security Requirements and Mitigate Security Risks. Requires an organization to identify and evaluate the security requirements for the software; determine what security risks the software is likely to face during operation and how the software's design and architecture should mitigate those risks; and justify any cases where risk-based analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design (secure by design) is key for improving software security and also helps improve development efficiency.
|
1.1 |
|
Specifies requirements in accordance with the DHS CISA Secure-by-Design Pledge, published by the U.S. Dept of Homeland Security (DHS) Cybersecurity and Infrastructure Agency (CISA). Requires an organization to apply patches directly for all of its cloud-based and Software-as-a-Service (SaaS) product and service offerings without requiring customer action.
|
1.0 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice RV.1: Identification and Confirmation of Vulnerabilities on an Ongoing Basis. Requires an organization to help ensure that vulnerabilities are identified more quickly so that they can be remediated more quickly in accordance with risk, reducing the window of opportunity for attackers.
|
1.1 |
|
Requirements for types of evidence collected as part of identity proofing.
|
3.0 |
|
Requirements for types of evidence collected as part of identity proofing for identity assurance level 3.
|
3.0 |
|
Requirements for verifying identity evidence at with moderate assurance.
|
3.0 |
|
Requirements for documenting the justification for each form of evidence the CSP collects and the strength of it's verification of the evidence.
|
3.0 |
