TBD

Vendor-Supported Products

TBD

Software and hardware of the system must be covered by security vulnerability support from the supplier.

References:

Asset reference: AS-LI-FUNCTION-05

Attacker reference: TBD

Validate that the supplier provides continuous vulnerability monitoring, timely advisories, and effective updates for all in-use software and hardware.

1. A complete system inventory (hardware and software, with versions) is available.

2. Supplier documentation regarding security support policy and timelines is available.

3. The system under test is currently within the vendor's standard support phase.

1. The tester obtains a list of recent Common Vulnerabilities and Exposures (CVEs) relevant to the in-use products from a third party independent of the vendor.

2. The tester verifies that advisories from the supplier match public CVE disclosures (cross-check NVD, vendor PSIRT, and CERT feeds).

3. The tester uses an automatic tool to scan for all CVEs affecting the product.

4. The tester verifies that the supplier provides either a patch or documented mitigation within a reasonable timeframe (e.g., within published SLA).

5. The tester checks that the update/mitigation can be applied or has been applied to the deployed version without loss of security support.

1. Supplier advisories cover all known CVEs relevant to the products in use.

2. Advisories are timely and consistent with industry disclosure best practices.

3. Updates or mitigations are available and applicable to the deployed system.

The following are acceptable:

1. Document what tool was used to automatically scan for CVEs.

2. Copy of supplier advisories.

3. Cross-reference table (inventory vs. CVE database vs. supplier feed).

4. Patch/mitigation bulletin and applied change record.

5. Plain-language conclusion confirming supplier monitoring and patching.

TBD

Configurable Cryptographic Methods

TBD

Applications must support configuration of cryptographic methods and provide functions to exchange encryption algorithms. Deactivation and modification capabilities (e.g., cipher suite adjustments) must be built during development. Functions to exchange encryption algorithms (re-encryption) apply only to persistent data storage, not to transport encryption. This enables substitution of broken schemes due to new attacks or future computing architectures.

References:

Asset reference: AS-LI-FUNCTION-05

Attacker reference: TBD

Verify that cryptographic methods are configurable and that applications can exchange encryption algorithms for persistent data storage. Ensure that cipher suite modification and algorithm substitution functions are implemented and usable.

1. Documentation of configurable crypto parameters and supported cipher suites is available.

2. Test data sets in persistent storage encrypted with an initial algorithm (e.g., AES-128-CBC) are prepared.

3. Administrative access to application configuration and key management is available.

1. Inspect code/configuration interfaces for crypto parameterization (cipher suites, key lengths, modes).

2. Modify crypto configuration to deactivate or change cipher suites (e.g., remove AES-128-CBC, enable AES-256-GCM).

3. Perform re-encryption of stored data from one algorithm to another.

4. Verify that transport encryption (e.g., TLS sessions) does not expose runtime re-encryption functions.

5. Negative: attempt re-encryption of transport sessions and confirm it is unsupported.

1. Application supports enabling/disabling and modification of cryptographic methods at configuration level.

2. Re-encryption of persistent data from one algorithm to another is successful.

3. Transport encryption is not subject to runtime re-encryption functions.

4. Attempts to re-encrypt transport sessions are rejected.

1. Configuration documentation and sample settings for cryptographic method changes.

2. Test logs showing cipher suite modification and successful re-encryption of persistent data.

3. Screenshots/configuration outputs verifying AES-128-CBC replaced with AES-256-GCM (or equivalent).

4. Negative test results confirming re-encryption of transport encryption is blocked.

TBD

CI/CD Separation

TBD

The CI/CD chain must be separate from systems that use it; there must exist no shared hosts/components/networks.

References:

Asset reference: AS-LI-FUNCTION-05

Attacker reference: TBD

The goal of this test is to verify that the CI/CD chain is fully separated from software/systems that use it (tenants), and that no tenant workloads (including jobs executed on runners) can reach or use CI/CD internal components (e.g., Source Code Management Database, runner management endpoints, internal message bus, package registry internals, artifact storage internals, management UIs).

1. CI/CD chain (e.g., GitLab/Gitea, runners, artifact store, container registry, internal DB/message bus) is deployed on hosts/subnets not shared with tenant systems.

2. At least one tenant project with functioning pipelines and a non-privileged runner scoped to that project/group exists.

3. The following CI/CD internals identified with network/host inventory exist:

a. SCM application nodes (control plane/API/UI)

b. SCM internal DB (e.g., PostgreSQL)

c. Runner management/control interfaces

d. Internal message bus/queues (if any)

e. Artifact store internal endpoints (not the public download URL)

f. Container/package registry internal endpoints

g. Admin/management interfaces (UI/API)

1. Network policy documents are available (firewall rules, ACLs, security groups, service mesh policies).

2. Admin credentials for CI/CD are separate from tenant accounts.

3. A "probe job" template the lab can run in a tenant pipeline (non-privileged) to attempt egress connections (TCP/UDP/HTTP(S)).

1. Host & Network Separation Check

a. Collect host inventory: confirm CI/CD nodes and tenant application nodes are distinct (no shared VMs/nodes).

b. Collect subnet/VLAN/Security Group definitions: CI/CD internals isolated from tenant subnets.

c. If Kubernetes is used, verify no shared Kubernetes namespaces or nodes between CI/CD control plane/runners and tenant apps.

1. Identity & Role Separation Check

a. Verify CI/CD admin accounts are not used for tenant repos or pipelines.

b. Verify runner registration tokens/credentials are not exposed in tenant projects.

c. Confirm tenant maintainers cannot access CI/CD system/global settings.

1. Network Reachability (Active) from Tenant Job

Using the probe job in a tenant pipeline (non-privileged runner):

a. Attempt TCP/UDP connections to each CI/CD internal component (list from Preconditions #3).

b. Attempt HTTP(S) GET/POST to CI/CD admin/management endpoints and runner management endpoints.

c. Attempt DNS resolution of internal hostnames (if split-DNS is used).

d. Attempt access to SCM internal DB (e.g., TCP 5432) and message bus ports.

e. Attempt access to artifact/registry internal endpoints (not public URLs).

f. Record results (connectivity blocked/allowed, HTTP status codes, TLS handshake outcomes).

1. Runner Boundary Enforcement

a. Inspect runner configuration: ensure no "privileged" or host-mounted sensitive paths that could expose CI/CD internals (e.g., docker.sock, host networking).

b. Validate runner scope: project/group-scoped; not shared globally with CI/CD internals.

c. If Kubernetes executors are used, validate network policies (no egress to CI/CD internals; default-deny/explicit-allow only to public endpoints required for builds).

1. Administrative Surface Isolation

a. From a tenant maintainer account, attempt to reach admin areas (system settings, user management, runner admin pages).

b. Verify HTTP(S) returns 403.404 or redirects to login without privilege escalation.

1. Logging & Detection

a. Confirm that blocked access attempts from the probe job are logged by Firewall/Web Application Firewall/service-mesh (and optionally alerted).

b. Verify CI/CD app logs show no successful privileged access from tenant identities.

1. Exception Handling (Self-Hosting Code Only, No Self-Deployment)

a. Create a repo that stores CI/CD deployment code (e.g., Ansible/Terraform) inside the CI/CD.

b. Ensure pipelines that would deploy/redeploy the CI/CD are disabled or blocked (e.g., protected branch rules, approval gates that prohibit execution, or policy-as-code denying these jobs).

c. Attempt to run a deployment pipeline; verify it is prevented per policy (store/test allowed; deploy not allowed).

1. Host/Network:

a. No shared compute nodes between CI/CD internals and tenant systems.

b. CI/CD internal subnets not routable from tenant runners/namespaces (default-deny in place).

1. Identity/Role:

a. Tenant identities cannot view/modify CI/CD global settings, runners, or secrets.

b. Runner tokens/registrations are compartmentalized; no cross-tenant leakage.

1. Reachability:

a. All direct connections from tenant jobs to CI/CD internals fail (SYN blocked, TLS handshake fails, HTTP 403.404 for public edges).

b. DNS for internal hostnames not resolvable from tenant jobs.

1. Runner Boundary:

a. Runners are non-privileged for tenant projects; no host networking, no docker.sock, no sensitive mounts (any volume/pipe/socket/device a runner job mounts that could give it control of the host, access to CI/CD internals, or long-lived secrets/credentials beyond that job's scope).

b. Runner scope does not include CI/CD administrative projects or org level.

1. Admin Surface:

a. Tenant maintainers cannot access admin/management pages or APIs.

1. Logging:

a. Blocked attempts are recorded with source project/runner identity and destination component; optional alert raised.

1. Exception (Self-Hosting Code):

a. Storing/testing CI/CD deployment code is allowed.

b. Any attempt to deploy CI/CD from within CI/CD is blocked by policy/gates; evidence shows prevented execution.

1. General:

a. If any internal endpoint is reachable from tenant jobs, this is a FAIL (a requirement violation).

b. Pay special attention to "hidden" internals exposed by misconfigured service discovery, sidecars, or shared node-locals (e.g., metadata services, registries on host network).

c. For Kubernetes: verify NetworkPolicy/CNI enforces default-deny egress from runner pods.

1. Host inventory (screenshots/exports) showing no shared hosts.

2. Network diagrams and effective firewall/security-group/service-mesh policies.

3. Runner configuration exports (executor type, privileges, scopes).

4. Pipeline logs from probe job showing connection failures & HTTP statuses.

5. CI/CD audit logs confirming no admin access by tenant identities.

6. Security device logs (Firewall/Web Application Firewall/service-mesh) showing blocked flows with timestamps.

7. Policy-as-code or CI settings demonstrating blocked self-deployment attempts (and the failed pipeline run).

T-LOG-01

Confidentiality of LI Identifiers

TS 33.126: R6.6 - 30 Undetectability by Non-Authorized Parties

General-purpose logs must not contain Lawful Interception (LI) identifiers or other sensitive LI information. Only LI-protected audit logs, only accessible to LI-cleared personnel, may contain such details.

References:

Asset reference: AS-LI-FUNCTION-05

Attacker reference: AT-INTERNAL-01

Validate that LI identifiers and LI-specific events are not written during provisioning activities to general-purpose system or application logs accessible by non-LI-authorized administrators.

1. LI functionality is activated and operational in the system under test.

2. A general-purpose logging subsystem (e.g., syslog, journald, or vendor-specific log service) is enabled.

3. A test operator has LI clearance and can initiate LI operations.

4. A test operator has administrator-level access to general-purpose logs but no LI clearance (to simulate risk exposure).

1. Initiate an LI session (e.g., activate an intercept, provision target identifiers).

2. Trigger LI-related events likely to produce logs (e.g., provisioning errors, interface restarts).

3. Collect all general-purpose logs from the system during and after LI operations.

4. Inspect logs for presence of LI identifiers (e.g., IMSI, MSISDN, warrant ID, intercept ID).

5. Repeat under different conditions (normal activation, error cases, reconfiguration).

1. General-purpose logs contain no LI identifiers or warrant information.

2. LI events in general-purpose logs, if present, are limited to non-sensitive metadata (e.g., "LI subsystem error" without identifiers).

3. Detailed LI logs with identifiers are only recorded in LI-protected audit logs, accessible to LI-cleared personnel.

1. Copy of collected general-purpose logs during LI activity.

2. Annotated inspection showing absence of LI identifiers.

3. Copy of LI-protected logs confirming that identifiers are only stored in the restricted audit facility.

4. Plain-language conclusion affirming compliance.

T-LOG-01

Confidentiality of LI Identifiers

TS 33.126: R6.6 - 30 Undetectability by Non-Authorized Parties

General-purpose logs must not contain sensitive LI information. Only LI-protected audit logs, only accessible to LI-cleared personnel, may contain such details. When identifiers of intercepted targets appear in general-purpose logs (e.g., as part of routine signaling or service activity), no additional information shall indicate that the subscriber is subject to Lawful Interception.

References:

Asset reference: AS-LI-FUNCTION-05

Attacker reference: AT-INTERNAL-01

Validate that general-purpose logs, while possibly containing subscriber identifiers as part of normal service records, do not contain information or markers that reveal LI surveillance activity.

1. LI provisioning is active for a target identifier in the system under test.

2. General-purpose logging (e.g., network event logs, call detail records, session initiation logs) is enabled and accessible to administrators without LI clearance.

3. The target subscriber initiates communication (e.g., call setup, session initiation, messaging).

1. Provision a target identifier for interception in the LI system.

2. Have the target subscriber initiate multiple communications (e.g., calls, sessions, messages).

3. Collect general-purpose logs generated during these communications.

4. Inspect logs for signs of surveillance context, such as:

a) Explicit LI-related flags, tags, or annotations.

b) Error messages referencing LI functions.

c) Duplicated or anomalous log entries indicating redirection or duplication of traffic.

1. Compare log entries of intercepted subscriber activity with log entries of non-intercepted subscribers for consistency.

1. General-purpose logs contain only routine identifiers and service-related information (e.g., IMSI, MSISDN, session IDs).

2. No indication is present that the subscriber is under interception (no LI flags, tags, error codes, or, particularly, duplicate entries).

3. Log patterns for intercepted subscribers are indistinguishable from non-intercepted subscribers.

4. Surveillance-related records are only present in LI-protected audit logs.

1. Copies of general-purpose logs showing intercepted and non-intercepted subscriber activities.

2. Annotated analysis demonstrating that intercepted subscriber logs do not reveal surveillance status.

3. Copy of LI-protected logs showing that surveillance records are confined to the restricted LI audit domain.

4. Plain-language conclusion confirming that LI activity remains undetectable in general-purpose logs.

TBD

Segregation of LI Logging

TS 33.126: R6.6 - 30 Undetectability by Non-Authorized Parties

LI audit and operational logs must be segregated from all non-LI logging subsystems. Access to LI logs must be restricted to LI-cleared personnel only.

References:

Asset reference: AS-LI-FUNCTION-05

Attacker reference: AT-INTERNAL-01

Validate that the LI logging subsystem is logically and physically segregated from non-LI (general purpose) logs, ensuring that LI log data cannot be accessed through non-LI interfaces or roles.

1. LI subsystem is deployed and active.

2. General-purpose system logging (e.g., syslog, journald, platform management logs) is operational.

3. LI-specific logging facility is configured and accessible only to LI-cleared roles.

4. Test operators possess two distinct roles: one LI-cleared and one non-cleared administrative account.

1. Generate LI-related events (e.g., provisioning, activation, LI delivery errors).

2. Generate non-LI system events (e.g., user login, system health checks, configuration updates).

3. Collect logs from both the LI logging subsystem and the general logging subsystem.

4. Attempt to access LI logs using the non-cleared administrator role.

5. Verify log storage segregation (e.g., separate file paths, databases, log streams).

6. Inspect general logs for any LI log entries, references, or cross-linkages.

1. LI log data is stored in a distinct, access-controlled subsystem.

2. LI logs are not visible through general log collectors, APIs, or management tools.

3. Non-LI logs do not contain pointers, cross-references, or metadata revealing LI activity.

4. Access attempts to LI logs by non-cleared roles are denied and auditable.

1. Copies of LI and non-LI log directories or service configuration showing segregation.

2. Access-control matrix demonstrating that only LI-cleared roles can access LI logs.

3. Screen captures or outputs of denied access attempts from non-cleared accounts.

4. Plain-language conclusion confirming effective segregation of LI and non-LI logging domains.

TBD

Vendor-Supported Products

TBD

Software and hardware of the system must be covered by security vulnerability support from the supplier.

References:

Asset reference: AS-LI-FUNCTION-05

Attacker reference: TBD

Ensure open-source components are covered by a reliable vulnerability management program (community or designated third party).

1. Inventory identifies open-source components in the system.

2. Evidence exists of an active community or commissioned third party maintaining vulnerability advisories.

3. Mailing lists, public trackers, or equivalent communication channels are accessible.

Note: the following shall be performed for each artifact.

1. The tester identifies open-source components in the Inventory.

2. The tester queries the community/project tracker for recent vulnerability advisories.

3. The tester selects one CVE from the tracker.

4. The tester verifies that either a patch release or mitigation note was published.

5. The tester checks that the patch/mitigation can be integrated into the deployed version in use.

1. Vulnerability monitoring exists and is demonstrably active.

2. Advisories are consistent with public CVE disclosures.

3. Patches/mitigations are available for exploitable vulnerabilities.

The following are acceptable:

1. Extracts from project mailing lists/trackers.

2. CVE reference with matching advisory.

3. Patch or workaround instructions.

4. Plain-language conclusion whether open-source support is reliable and comprehensive.

TBD

Trusted sources

TBD

All software used on the system (firmware, OS, libraries, applications, appliances, containers) must be obtained from trusted sources (official supplier channels, authorized distributors, or official provisioning servers with validated cryptographic protection).

References:

Asset reference: AS-LI-FUNCTION-05

Attacker reference: TBD

Ensure software is only obtained from official supplier channels, authorized distributors, or trusted provisioning servers.

1. Inventory of software/firmware to be obtained.

2. Supplier documentation of official distribution channels exists and is obtained.

3. Access to logs of package managers or download clients is available.

Note: the following shall be performed for each artifact.

1. Attempt to download artifacts from an official supplier server with HTTPS/sFTP.

2. Validate TLS certificate/host key against supplier reference values.

3. [Prefer]{.mark}(?) cryptographically signed/hashed artifacts where available. [Editor's Note: Question: Allow variance or not?]{.mark}

4. Negative test: attempt download from a non-authorized mirror or staging server with invalid cert; confirm abort. [Editor's Note: Answer to the previous question affects this.]{.mark}

1. Only artifacts from trusted sources are accepted. [Editor's Note: Answer to the previous question affects this.]{.mark}

2. Certificates/keys validated; untrusted endpoints blocked.

3. Signed/hashed artifacts are used in preference to unprotected ones.

1. Download logs with FQDN/IP and TLS details.

2. Certificate/host key validation records.

3. Supplier list of approved channels cross-referenced with observed downloads.

4. Plain language conclusion.

TBD

Integrity checking

TBD

All software used on the system (e.g., firmware, OS, libraries, applications, appliances, containers) must be verified for integrity before installation (e.g., supplier-provided hashes, signatures, Certificate of Authenticity on physical media)

References:

Asset reference: AS-LI-FUNCTION-05

Attacker reference: TBD

Ensure downloaded software is integrity-verified using supplier-provided checksums or signatures.

1. Supplier-provided checksum/signature available.

2. Verified trust anchors for signature validation exist and are accessible.

3. Local verification tools available (sha256sum, gpg, etc.) are available.

1. Compute cryptographic hash of the artifact; compare with supplier reference from an independent channel.

2. If available, verify cryptographic signature (e.g., GPG/X.509).

3. Negative test A: modify artifact (bit flip); confirm hash/signature fails.

4. Negative test B: attempt to install artifact with forged signature; confirm block/failure.

1. Hash/signature verification passes before install.

2. Any mismatch or invalid signature aborts install.

1. Hash verification output.

2. Signature verification transcript (key fingerprint, issuer, validity).

3. Plain language conclusion.

T-INTERFACE-SEC-10, T-FEATURE-11

Feature Deactivation

TBD

Features that are not required in the software and hardware used shall be deactivated.

References:

Asset reference: AS-LI-FUNCTION-05, AS-API-CONF-10

Attacker reference: AT-INTERNAL-01, AT-EXTERNAL-02

During the initial installation of software, default-activated services that are not necessary for the operation and functionality of the specific system shall be disabled. These features typically cannot be uninstalled individually but must be deactivated via configuration settings. Disabled features shall remain permanently inactive across reboots.

Similarly, unnecessary hardware functions (e.g., unused interfaces) must be permanently disabled during initial commissioning.

Inactive features reduce the system's attack surface and minimize opportunities for unauthorized access, manipulation, or information leakage.

1. A complete system inventory (software modules, hardware interfaces) exists.

2. Documentation from suppliers listing configurable features is available.

3. Access to system configuration and runtime verification tools is available.

1. Enumerate all enabled software features and hardware interfaces at installation/commissioning.

2. Compare enumerated list with operational requirements; mark unnecessary features.

3. Disable each unnecessary feature via configuration (software) or BIOS/firmware settings (hardware).

4. Reboot/restart the system; verify disabled features remain inactive.

5. Attempt negative tests:

a. Access a disabled service or interface and confirm rejection.

b. Re-enable a disabled feature without explicit administrator action, and confirm block/failure.

1. Cross-check runtime logs and monitoring to ensure no activation after reboot.

1. Only features required for LI system operation remain active.

2. Disabled features remain inactive across reboots and cannot be accessed.

3. Negative tests confirm blocked access or failure of unauthorized re-enablement.

1. Inventory with list of active vs. disabled features.

2. Configuration files or screenshots showing deactivation.

3. Runtime verification output after reboot.

4. Logs confirming rejected access to disabled features.

5. Plain-language conclusion confirming permanent deactivation.

T-INTERFACE-SEC-10, T-FEATURE-11

Service Deactivation

TBD

Only services necessary for system operation may remain active. All supplier-preset, local, or network-accessible services that are not required for the LI system (e.g., default web servers or file-sharing daemons that are not part of LI operation) shall be disabled immediately after installation. Further, less secure management protocols (e.g., Telnet, FTP) shall be removed in favor of more secure alternatives.

Disabled services shall remain inactive across system restarts.

References:

Asset reference: AS-LI-FUNCTION-05, AS-API-CONF-10

Attacker reference: AT-INTERNAL-01, AT-EXTERNAL-02

Unnecessary services increase the system's attack surface and risk of compromise, particularly since such services are rarely optimized for secure operation.

1. Inventory of all services running after system installation exists.

2. Documentation identifying required services for LI system operation is available.

3. Access to system configuration and runtime service status is available.

1. Enumerate all running services after installation.

2. Compare list with documented operational requirements, and mark unnecessary services.

3. Disable identified services via configuration or package management.

4. Reboot the system; verify disabled services do not restart.

5. Negative test: attempt to connect to a disabled service remotely or locally; confirm access is denied.

1. Only necessary services remain active.

2. Disabled services remain inactive across restarts.

3. Unauthorized attempts to access disabled services fail.

1. Inventory with required vs. disabled service list.

2. Service configuration files or screenshots showing deactivation.

3. Logs confirming rejection of access attempts.

4. Plain-language conclusion confirming that unnecessary services remain disabled.

TBD

Standard Cryptographic Primitives

TBD

Only standardized cryptographic algorithms and primitives published by accredited organizations shall be used.

References:

Asset reference: AS-LI-FUNCTION-05

Attacker reference: TBD

All cryptographic algorithms, primitives, protocols, and parameters used in development and integration shall conform to standards published by accredited bodies (e.g., ETSI, SOGIS, NIST, ISO/IEC, IETF, BSI). Any deviation shall be itemized and justified.

1. Approved cryptographic policy/whitelist (algorithms, modes, curves, key sizes, digests, KDFs/MACs from e.g., ETSI, SOGIS, NIST, ISO/IEC, IETF, BSI) is available.

2. Inventory of crypto dependencies (libs, HSMs, protocol stacks) is available.

3. Access to code/configs/binaries and running services exists.

1. Extract crypto usages from code/configs/binaries (static analysis, grep, library settings).

2. Enumerate supported/negotiated ciphers on network services (e.g., testssl.sh, nmap --script ssl-enum-ciphers).

3. Compare against the whitelist and accredited standards.

4. Negative: attempt to enable a disallowed algorithm/mode (e.g., RC4, MD5, SHA-1 signatures, 3DES, RSA-1024) and confirm the pipeline or config hardening blocks it.

1. Only approved algorithms are present/negotiable; deprecated/non-standard options are disabled.

2. Attempts to enable disallowed crypto are rejected by Continuous Integration/policy or runtime controls.

1. List of accreditation bodies and standards used

2. Whitelist policy + mapping table.

3. Scanner outputs and config snippets showing allowed sets.

4. Logs showing rejection of disallowed algorithms.

TBD

Standard Crypto Libraries

TBD

Well-established and up-to-date cryptographic libraries must be used to implement cryptographic algorithms. The use of self-implemented cryptographic methods is prohibited unless explicitly required, in which case such implementations must follow industry best practices.

References:

Asset reference: AS-LI-FUNCTION-05

Attacker reference: TBD

Ensure that only well-established and up-to-date cryptographic libraries are used. Self-implemented cryptographic methods shall be avoided unless justified.

1. Approved crypto library whitelist (e.g., Botan, Bouncy Castle, GnuTLS, OpenSSL, wolfCrypt) is defined and available.

2. Inventory of crypto dependencies (source code, third-party libraries, protocol stacks, HSMs) is available.

3. Access to build environment, code repositories, and runtime binaries is granted.

1. Identify and extract all cryptographic function calls from source code and binaries (static analysis, code review, dependency scanners).

2. Cross-check identified crypto usages against the whitelist of approved libraries.

3. Verify library versions against latest available patched releases (e.g., OpenSSL Security Advisory, distro package versions).

4. Negative: Introduce a self-implemented crypto routine (e.g., custom AES, SHA-1 hash function, RC4 fallback) and verify that security review/Continuous Integration policy blocks or flags it.

1. Only approved and up-to-date crypto libraries are used.

2. Deprecated, self-implemented, or unapproved crypto code is absent or explicitly documented and justified under supervision.

3. Vulnerable or outdated library versions are flagged for update.

1. List of approved crypto libraries and current versions.

2. Dependency scanner output or inventory including crypto libraries.

3. Security advisories mapping showing libraries are up-to-date.

4. Logs or CI reports showing rejection of self-implemented crypto functions.

TBD

Modular Cryptographic Implementations

TBD

Cryptographic methods must be implemented in replaceable modules. Static implementations are prohibited, as they hinder corrections, replacements, and upgrades in the event of security incidents, evolving threats (e.g., quantum computing), or changing performance requirements. Implementations must allow seamless substitution of algorithms and provide sufficient hardware resources to support stronger cryptographic methods.

References:

Asset reference: AS-LI-FUNCTION-05

Attacker reference: TBD

Verify that cryptographic methods are implemented in modular, replaceable components such that algorithms, key lengths, or libraries can be substituted without requiring major redesign or system downtime.

1. System architecture documentation describing cryptographic module boundaries is available.

2. Inventory of cryptographic libraries and their integration points is available.

3. Test environment with ability to swap crypto libraries/configurations is set up.

1. Inspect software design and code for modular integration of cryptographic functions (e.g., plugin, API, or dynamic linking approach).

2. Attempt replacement of an existing crypto library with an alternative approved one (e.g., replace OpenSSL with GnuTLS, or update a library version).

3. Validate system operation with substituted algorithm or key length.

4. Negative: attempt to hard-code or statically link crypto algorithm implementations and verify that this is detected and flagged.

1. Cryptographic functions are implemented as replaceable modules (dynamic, configurable, or API-based).

2. System continues to operate correctly after replacing an algorithm or library.

3. Statically embedded or hard-coded cryptographic implementations are absent or flagged as non-compliant.

4. Hardware resources (e.g., CPU, HSM, accelerator capacity) are sufficient to handle stronger crypto algorithms when required.

1. Architecture documentation showing modular crypto design.

2. Test logs or CI outputs demonstrating successful swap of crypto libraries/algorithms.

3. Configuration or build scripts showing dynamic linking or pluggable crypto modules.

4. Negative test evidence showing static or hard-coded crypto is rejected.