| Trustmark Definition Name | Version |
|---|---|
|
The requirements for a CSP to adhere to appropriate security controls.
|
3.0 |
|
Requirement that identity proofing not be performed to determine eligibility for services or benefits.
|
3.0 |
|
The requirements for a CSP to identity proof Trusted Referees at an equivalent or higher assurance level then that of regular applicants.
|
3.0 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice PO.5: Implementation and Maintenance of Secure Environments for Software Development. Requires an organization to ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained within them. Examples of environments for software development include development, build, test, and distribution environments.
|
1.1 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice PO.2: Implementation of SDLC Roles and Responsibilities. Requires an organization to ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the SDLC.
|
1.1 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice PO.3: Implementation of SDLC Supporting Toolchains. Requires an organization to use automation to reduce human effort and improve the accuracy, reproducibility, usability, and comprehensiveness of security practices throughout the SDLC, as well as provide a way to document and demonstrate the use of these practices. Toolchains and tools may be used at different levels of the organization, such as organization-wide or project-specific, and may address a particular part of the SDLC, like a build pipeline.
|
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 include accurate common weakness enumeration (CWE) and common platform enumeration (CPE) fields in every common vulnerability and exposure (CVE) record that it publishes about its products and services.
|
1.0 |
|
The requirements for sufficient complexity when performing Knowledge Based Verification.
|
3.0 |
|
The requirements for Knowledge Based Verification to be opted out of by an applicant.
|
3.0 |
|
The requirements for the sources of information used in Knowledge Based Verification.
|
3.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 use time-limited setup passwords that auto-disable after configuration completion, 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 implement a machine-readable vulnerability disclosure policy (VDP), e.g., in a 'security.txt' file, for accessibility by vulnerability researchers.
|
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 develop and implement an organizational memory-safety roadmap to transition all of its product and service offerings to memory-safe languages.
|
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 enable multi-factor authentication (MFA) by default for all users and administrators upon first registration, 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 implement user prompts or reminders to encourage adoption of multi-factor authentication (MFA), e.g., through seat belt chimes, banners, interstitials, etc., 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 prioritize adoption of phishing-resistant multi-factor authentication (MFA) for administrative accounts, 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 enforce use of parameterized database queries to prevent SQL injection attacks, 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 issue common vulnerability and exposure (CVE) notices promptly for all critical/high-impact vulnerabilities requiring customer action or under active exploitation, for all of its product and service offerings.
|
1.0 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice PS.1: Protection of All Forms of Code from Unauthorized Access and Tampering. Requires an organization to help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the software. For code that is not intended to be publicly accessible, this helps prevent theft of the software and may make it more difficult or time-consuming for attackers to find vulnerabilities in the software.
|
1.1 |
|
Specifies requirements in accordance with NIST Secure Software Development Framework (SSDF), version 1.1, Practice PS.2: Provision of a Mechanism for Verifying Software Release Integrity. Requires an organization to help software acquirers ensure that the software they acquire is legitimate and has not been tampered with.
|
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 publicly document its common vulnerability and exposure (CVE) issuance policies and also encourage CVE filing for lower-severity vulnerabilities.
|
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 publish root-cause analyses of common vulnerabilities and exposures (CVEs), 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 periodically publish statistics on its products that are still using default passwords, as well as progress of customer efforts to migrate away from default passwords.
|
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 periodically publish aggregate statistics on the adoption of multi-factor authentication (MFA) within its products and services, categorized by user type and MFA method.
|
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 publish patch adoption rates by product version over time, across all of its product and service offerings.
|
1.0 |
