Open-source tools for NIST CSF 2.0 outcomes

Govern and identify outcomes are mostly decisions, records and inventories, so these tools hold and date the evidence rather than make the decisions. CISO Assistant can hold NIST CSF 2.0 assessment results, owners and linked evidence, while Wazuh Syscollector and Greenbone supply the asset and vulnerability data that the Identify Categories depend on.

• Assessment records in CISO Assistant: the platform ships NIST CSF among more than 200 frameworks and runs assessments against them, so each Subcategory result can carry an owner, a status and linked evidence. Confirm how the CSF 2.0 library is loaded in your version.
• Syscollector inventory exports (ID.AM): exports of hardware, operating system, installed software, network interfaces, open ports and users give the assessor a dated view of the asset base. The export only shows what each agent reports, so compare it with the asset register.
• Scan reports for risk assessment (ID.RA): Greenbone scan results built on the Community Feed show tested vulnerabilities per target. The assessor will want the scan scope, the feed date and how findings became risk decisions.
• Items the assessor still asks for: an approved cybersecurity risk management policy, named roles and authorities, data flow maps, supplier lists and risk acceptances signed by leadership. No scanner or inventory produces these.

Check that each inventory export is dated, limited to the systems in your assessment boundary, and linked to a named owner in the risk record.

Protect outcomes are tested through configuration and access evidence. Keycloak produces the authentication settings, Wazuh Syscollector shows account and software state on endpoints, and restic records the backup repository behind the data security Subcategories. The assessor then checks whether those settings match the approved standard and operated across the assessment period.

• Keycloak MFA policy settings: realm configuration covering two-factor authentication, passkeys, recovery codes and TOTP or HOTP settings, including one-time password policy values and W3C WebAuthn settings. Keep a dated export and the change history for each setting.
• Enrollment and access records: user and group listings showing who has MFA enrolled and who holds privileged access. The assessor will sample accounts and compare them with HR records and access approvals.
• restic check output: restic check verifies the structural consistency of snapshots, trees and pack files. Adding --read-data or --read-data-subset reads pack files back to confirm the stored data is unmodified, and the log of each run becomes evidence.
• Items still needed: an approved authentication standard, exception approvals for any account without MFA, configuration change approvals, and security awareness and role-based training records for the PR.AT Subcategories.

Confirm that the Keycloak export and restic logs cover the full assessment period, not a single day selected for the audit.

Detect evidence is high in volume, so assessors focus on three questions: is monitoring configured, are alerts reviewed, and can the review be traced. Wazuh supplies both the rule logic and the alert trail, while scheduled Greenbone scans can add periodic checks for exposed services that monitoring alone may miss.

• Rule coverage: Wazuh decodes collected logs and compares each event against more than 3,000 built-in rules and decoders plus any custom rules. Export the rule set in use and show which log sources feed it, since the Continuous Monitoring Subcategories expect coverage of networks, endpoints and personnel activity.
• Alert trail: matching alerts are written to alerts.log and alerts.json and mapped to MITRE ATT&CK. These files show what fired and when, but they do not show who reviewed each alert.
• Dashboard review records: alerts forwarded to the Wazuh indexer are reviewed in the dashboard. Keep triage notes or ticket references so the assessor can follow an alert to its disposition.
• Items the assessor still asks for: a log source inventory, retention settings, monitoring of external service providers, and proof that detection rules were adjusted after tests or incidents.

Sample a set of alerts and confirm that each has a documented disposition, then confirm the rules that fired were active on the date shown.

Respond outcomes are tested through the incident record. DFIR-IRIS keeps each case as one record, so an assessor can trace an alert from intake through triage, investigation tasks, evidence and reporting. The tool supports the incident management, incident analysis and reporting Categories, but the assessor will still need the response plan and the decisions on notifications.

• Case records: each case holds assets, indicators of compromise, tasks and evidence with a full audit trail that shows who changed what and when.
• Triage intake: alerts from SIEM, EDR and REST sources are triaged into cases, which provides evidence of the categorization and prioritization step.
• Evidence integrity: evidence is logged with SHA-256 verification and chain of custody. Record the hash at intake and verify it again whenever the evidence is used or handed over.
• Timeline and reports: the consolidated investigation timeline and reports generated from case data support root cause analysis and stakeholder communication records.
• Items still needed: the approved incident response plan, decision records for regulator or customer notifications, communication logs, and lessons-learned records after each incident.

Test one closed case end to end, from alert intake to the final report, and confirm that the audit trail and evidence hashes are intact.

Recover evidence depends on showing that backups are restorable and unmodified. restic's check command confirms repository structure, and its data-reading options confirm that stored pack files are intact. These results prove backup integrity, but the recovery Subcategories also ask whether systems were restored and recovery was declared complete, which needs records beyond the backup tool.

• Structural check output: restic check verifies the consistency of snapshots, trees and pack files. Save each output with the repository name and the run date.
• Data read verification: restic check --read-data reads every pack file, while --read-data-subset checks part of the repository. Record which option ran and how often, because a subset does not prove the whole repository is intact.
• Restore test records: the backup tool does not show that a system was restored. Keep records of test restores, including what was restored, the outcome and any defects found, to support verification of restored assets.
• Items still needed: recovery objectives set by the business, the recovery plan and its priorities, sign-off that recovery is complete, and communication records for stakeholders.

Confirm that backup check logs and restore test records reference the same repository and period, so the assessor can connect them.