SOX Change Log Checker
Clause text

NIST SP 800-53 Rev 5: the clauses the checker cites

The 8 NIST SP 800-53 Rev 5 clauses behind the findings, each with the evidence an auditor asks for where it is held.

Our statement of each clause, read against the copy we hold and cited to it; it is not the instrument's verbatim wording.

8 clauses

SP 800-53 CM-3 Configuration change control

Requires the types of change that fall under configuration control to be defined, proposed changes to be reviewed and approved or rejected with explicit consideration of security and privacy impact, decisions and implemented changes to be documented, change records to be retained for a defined period, and change activity to be monitored and reviewed by the responsible body.

Evidence an auditor expects: Documented definition of which change types are configuration controlled; Change records showing security and privacy impact considered before approval; Change advisory board or approver minutes recording decisions; Retention evidence for change records against the defined period; Post-implementation review or monitoring output for change activity
Where it usually falls short: Emergency changes bypass approval and are never retrospectively documented; Impact analysis recorded as a tick box with no security reasoning behind it
Source: NIST SP 800-53 Rev 5
SP 800-53 CM-4 Impact analyses

Requires changes to the system to be analysed for their potential security and privacy impact before they are implemented, so that the consequences of a change are understood while it can still be stopped or modified.

Evidence an auditor expects: Impact analysis records attached to change requests before implementation; Method or checklist used to assess security and privacy impact; Examples of changes rejected or modified because of the analysis; Evidence that the analysis considers privacy as well as security effects
Where it usually falls short: Analysis performed after deployment as part of a review rather than beforehand; Privacy impact never considered, only availability and security
Source: NIST SP 800-53 Rev 5
SP 800-53 CM-5 Access restrictions for change

Requires physical and logical access restrictions on who may make changes to the system to be defined, documented, approved and actually enforced, so that only authorized personnel can alter the system.

Evidence an auditor expects: Documented and approved restrictions on who may change what; Access control configuration for production change paths and deployment pipelines; Records showing enforcement, for example rejected unauthorized deployments; Review of privileged change access against the approved list
Where it usually falls short: Developers hold standing write access to production alongside the pipeline; Restrictions documented but not enforced, so the pipeline can be bypassed manually
Source: NIST SP 800-53 Rev 5
SP 800-53 CM-9 Configuration management plan

Requires a configuration management plan for the system that sets out roles, responsibilities and processes, establishes how configuration items are identified and managed across the development life cycle, names the configuration items placed under management, is reviewed and approved by defined personnel, and is itself protected from unauthorized disclosure and modification.

Evidence an auditor expects: Approved configuration management plan with roles, processes and approval signatures; Configuration item register showing what is under configuration management; Evidence of the identification process applied across the development life cycle; Storage and permission settings that keep the configuration management plan from unauthorized change
Where it usually falls short: Plan describes a process that the delivery teams do not follow; Configuration items never formally identified, so the plan has no subject
Source: NIST SP 800-53 Rev 5
SP 800-53 AC-5 Separation of duties

Requires the organization to identify and document the individual duties that must be kept apart to limit malevolent activity without collusion, and to define system access authorizations so that those duties cannot be exercised by one person.

Evidence an auditor expects: Documented conflicting duty pairs for the mission and system in question; Role definitions and entitlement mapping showing conflicting duties are not held together; Toxic combination report from the identity system or a manual conflict analysis; Approved exceptions with the compensating detective controls applied
Where it usually falls short: Conflicting duties named for finance processes only and never for system administration; Small teams create unavoidable conflicts that are tolerated rather than documented and compensated
Source: NIST SP 800-53 Rev 5
SP 800-53 SA-10 Developer configuration management

Requires the developer of the system, component or service to perform configuration management during defined life cycle stages, to document and control the integrity of changes to defined configuration items, to implement only organization-approved changes, to document approved changes with their potential security and privacy impacts, and to track security flaws and their resolution and report findings to defined personnel.

Evidence an auditor expects: Contract or agreement clauses imposing developer configuration management duties; Developer change records showing approval before implementation; Documented configuration items under developer configuration management; Flaw tracking records and reports received from the developer
Where it usually falls short: Obligations assumed from the developer's own process with nothing in the contract; No visibility of developer changes, so approval is nominal
Source: NIST SP 800-53 Rev 5
SP 800-53 SA-11 Developer testing and evaluation

Requires the developer, at all stages after design, to plan and perform ongoing security and privacy control assessment, to carry out defined testing types at a defined frequency, depth and coverage, to produce evidence of the assessment plan being executed and its results, to implement a verifiable flaw remediation process, and to correct the flaws that testing identifies.

Evidence an auditor expects: Developer assessment and test plan covering the required testing types; Test execution evidence and results supplied by the developer; Flaw remediation records showing identified flaws corrected and verified; Contract clauses requiring the testing depth, coverage and frequency
Where it usually falls short: Testing evidence claimed but never provided to the organization for review; Depth and coverage undefined, so a single scan satisfies the requirement on paper
Source: NIST SP 800-53 Rev 5
SP 800-53 SI-7 Software, firmware, and information integrity

Requires integrity verification tools to be employed to detect unauthorized changes to organization-defined software, firmware and information, and requires organization-defined actions to be taken when such unauthorized changes are detected.

Evidence an auditor expects: Defined list of software, firmware and information subject to integrity verification; Integrity monitoring tool configuration and coverage report; Alerts generated by integrity checks and the response records; Documented actions to be taken on detection of unauthorized change
Where it usually falls short: Integrity monitoring produces constant noise from routine change and is therefore ignored; Firmware excluded because tooling only covers the operating system layer
Source: NIST SP 800-53 Rev 5