Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions ASSESSMENT_CATALOG/3_Test_Procedures/RS/RS.AN-06.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,7 @@
- [ ] Evidence storage access control configuration
- [ ] Incident record retention policy
- [ ] Sample evidence catalog from a recent incident
- [ ] [Evidence Preservation Guide](../../5_Artifacts/Procedures/PROC-evidence-preservation-guide.md) (ALMA-SOP-2025-010b)

---

Expand Down
1 change: 1 addition & 0 deletions ASSESSMENT_CATALOG/3_Test_Procedures/RS/RS.AN-07.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,7 @@
- [ ] Evidence storage access control lists
- [ ] Sample chain-of-custody documentation from recent incident
- [ ] Automated collection tool output logs
- [ ] [Evidence Preservation Guide](../../5_Artifacts/Procedures/PROC-evidence-preservation-guide.md) (ALMA-SOP-2025-010b)

---

Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,126 @@
# Evidence Preservation Guide (Excerpt)

| Field | Value |
|-------|-------|
| **Procedure ID** | ALMA-SOP-2025-010b |
| **Version** | 1.0 |
| **Effective Date** | March 1, 2025 |
| **Last Reviewed** | February 16, 2026 |
| **Procedure Owner** | Nadia Khan, Detection & Response Lead |
| **Approved By** | CISO |
| **Classification** | Internal Use Only |

---

## 1. Purpose

This guide defines how the Detection & Response team collects, preserves, and documents evidence
during incident investigations, so that investigation actions and collected data remain complete,
attributable, and defensible after the fact. It is the companion procedure to the [Incident Response
Playbook](PROC-incident-response-playbook.md) (ALMA-SOP-2025-010), referenced there under Related
Documents but not previously written up as a standalone guide.

---

## 2. Scope

Applies to all evidence gathered during Phase 1 (Detection and Triage) through Phase 3 (Eradication)
of the Incident Response Playbook, across Alma's detection and response tooling: SentinelOne EDR, AWS
GuardDuty, CloudTrail, VPC Flow Logs, and ServiceNow incident tickets. Does not cover litigation-hold
or law-enforcement chain-of-custody requirements, which are handled jointly with Legal on a
case-by-case basis per the playbook's Communication section.

---

## 3. Evidence Types and Collection Priority

Evidence is collected in order of volatility — the most perishable state first:

| Priority | Evidence Type | Example Source |
|----------|---------------|-----------------|
| 1 (most volatile) | Active memory, running processes, active network connections | SentinelOne Deep Visibility live query |
| 2 | Volatile network state | VPC Flow Logs, active GuardDuty findings |
| 3 | Authentication and API activity | CloudTrail, corporate SSO (Active Directory) authentication logs |
| 4 | Persistent host artifacts | SentinelOne endpoint file/registry snapshots |
| 5 (least volatile) | Ticket and communication records | ServiceNow incident ticket, Slack #soc-alerts export |

Responders capture Priority 1–2 evidence during the Investigation step (Playbook §4.2) before any
containment action that could disrupt it — for example, before a SentinelOne network quarantine or an
IAM deny-all policy attachment, both of which can end an active session before its state is captured.

---

## 4. Collection Procedures

1. **SentinelOne evidence** — export the Deep Visibility query results (process tree, network
connections, file modifications) for the affected endpoint as a timestamped report attached
directly to the ServiceNow incident ticket.
2. **GuardDuty evidence** — export the full finding JSON, not a summary screenshot, so the original
metadata (finding ID, severity, resource ARN, first/last observed timestamps) is preserved intact.
3. **CloudTrail evidence** — query API activity for the affected IAM identity across the incident
window and export the result set; note the query parameters used alongside the export so the
collection is reproducible.
4. **Ticket and communication evidence** — attach exports directly to the ServiceNow incident ticket
rather than linking to a source system that may later be modified, quarantined, or expire logs
under its own retention schedule.

---

## 5. Integrity Controls

- Every exported evidence file is hashed (SHA-256) at the time of collection, and the hash is recorded
in the ServiceNow ticket alongside the file.
- Evidence attached to a ServiceNow ticket inherits ServiceNow's audit logging — any modification to
an attachment is recorded with the modifying user and timestamp, satisfying the tamper-evidence
requirement without a separate storage system.
- Access to closed-incident tickets and their evidence attachments is restricted to the Detection &
Response team and Internal Audit; access is logged.

---

## 6. Chain of Custody and Provenance Documentation

For each evidence item, the collecting analyst records directly on the ServiceNow ticket:

- **Source system** the evidence was collected from
- **Collector** — the analyst's identity
- **Timestamp** of collection
- **Method** — the specific export/query used (Section 4)
- **Hash** at time of collection (Section 5)

If an evidence item is later transferred between personnel (for example, from the initial responder
to whoever performs root-cause analysis under the playbook's §8.2 Post-Incident Review), the transfer
is logged as a ServiceNow ticket comment naming both parties and the timestamp, so the custody trail
has no gap between collection and analysis.

---

## 7. Retention

Evidence attached to a ServiceNow incident ticket is retained per the ticket's own record retention
schedule, which follows the [Information Security Policy](../Policies/POL-information-security.md)
(ALMA-POL-2025-001). Evidence relevant to an incident still under active review by Internal Audit or
Legal is held past the standard schedule until that review closes, consistent with the Business
Continuity Plan (ALMA-SOP-2025-013).

---

## Related Documents

| Document | Reference |
|----------|-----------|
| Incident Response Playbook | ALMA-SOP-2025-010 |
| Information Security Policy | ALMA-POL-2025-001 |
| Business Continuity Plan | ALMA-SOP-2025-013 |

---

## Version History

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | March 1, 2025 | N. Khan | Initial guide |

---

*This is a fictional example created for educational purposes.*
6 changes: 3 additions & 3 deletions src/data/communityProcedures.json
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
{
"bankVersion": "47e1c68ed81d375c",
"bankVersion": "61b4d2be5f1e7ea9",
"procedureCount": 106,
"source": "ASSESSMENT_CATALOG/3_Test_Procedures",
"procedures": {
Expand Down Expand Up @@ -475,12 +475,12 @@
},
"RS.AN-06": {
"title": "RS.AN-06: Investigation Action Recording Test Procedures",
"markdown": "# RS.AN-06: Investigation Action Recording Test Procedures\n\n**CSF Subcategory:** RS.AN-06 - Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved\n\n---\n\n## Test Procedures\n\n1. **Review investigation documentation requirements**\n - Obtain incident response policy sections governing investigation record-keeping\n - Verify requirements for individual responder action logging during incidents\n - Confirm the incident lead role and responsibilities for documentation oversight are defined\n - Check that evidence chain-of-custody procedures are documented\n\n2. **Examine investigation records for completeness**\n - Pull 3-5 recent incident tickets from ServiceNow (TKT-SOC series)\n - Verify each ticket contains timestamped action logs from individual responders\n - Confirm the incident lead documented the incident narrative with supporting evidence\n - Check that all investigation steps are traceable and attributed to specific personnel\n\n3. **Validate record integrity and preservation controls**\n - Review ServiceNow audit logging configuration for SOC ticket modifications\n - Verify incident records cannot be altered without audit trail\n - Confirm evidence storage locations have access controls and integrity verification\n - Check retention periods for investigation records against policy requirements\n\n4. **Test provenance tracking for collected evidence**\n - Select a recent incident and trace evidence from collection through analysis\n - Verify evidence items are cataloged with source, collector, timestamp, and hash values\n - Confirm digital evidence handling follows documented forensic procedures\n - Check that evidence is stored in tamper-evident or write-once storage\n\n---\n\n## Evidence Requests\n\n- [ ] Incident response policy (investigation documentation section)\n- [ ] 3-5 ServiceNow SOC tickets with investigation action logs\n- [ ] ServiceNow audit log configuration for incident tickets\n- [ ] Evidence chain-of-custody procedures\n- [ ] Evidence storage access control configuration\n- [ ] Incident record retention policy\n- [ ] Sample evidence catalog from a recent incident\n\n---\n\n## Notes\n\nThis test procedure validates that investigation actions are systematically recorded with integrity and provenance controls. Mature organizations maintain detailed, tamper-evident investigation logs attributed to individual responders, with the incident lead responsible for comprehensive documentation. The integrity of these records is critical for post-incident reviews, legal proceedings, and regulatory compliance. ServiceNow ticket audit trails provide a baseline, but dedicated evidence management may be needed for complex incidents.",
"markdown": "# RS.AN-06: Investigation Action Recording Test Procedures\n\n**CSF Subcategory:** RS.AN-06 - Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved\n\n---\n\n## Test Procedures\n\n1. **Review investigation documentation requirements**\n - Obtain incident response policy sections governing investigation record-keeping\n - Verify requirements for individual responder action logging during incidents\n - Confirm the incident lead role and responsibilities for documentation oversight are defined\n - Check that evidence chain-of-custody procedures are documented\n\n2. **Examine investigation records for completeness**\n - Pull 3-5 recent incident tickets from ServiceNow (TKT-SOC series)\n - Verify each ticket contains timestamped action logs from individual responders\n - Confirm the incident lead documented the incident narrative with supporting evidence\n - Check that all investigation steps are traceable and attributed to specific personnel\n\n3. **Validate record integrity and preservation controls**\n - Review ServiceNow audit logging configuration for SOC ticket modifications\n - Verify incident records cannot be altered without audit trail\n - Confirm evidence storage locations have access controls and integrity verification\n - Check retention periods for investigation records against policy requirements\n\n4. **Test provenance tracking for collected evidence**\n - Select a recent incident and trace evidence from collection through analysis\n - Verify evidence items are cataloged with source, collector, timestamp, and hash values\n - Confirm digital evidence handling follows documented forensic procedures\n - Check that evidence is stored in tamper-evident or write-once storage\n\n---\n\n## Evidence Requests\n\n- [ ] Incident response policy (investigation documentation section)\n- [ ] 3-5 ServiceNow SOC tickets with investigation action logs\n- [ ] ServiceNow audit log configuration for incident tickets\n- [ ] Evidence chain-of-custody procedures\n- [ ] Evidence storage access control configuration\n- [ ] Incident record retention policy\n- [ ] Sample evidence catalog from a recent incident\n- [ ] [Evidence Preservation Guide](https://github.com/CPAtoCybersecurity/csf_profile/blob/main/ASSESSMENT_CATALOG/5_Artifacts/Procedures/PROC-evidence-preservation-guide.md) (ALMA-SOP-2025-010b)\n\n---\n\n## Notes\n\nThis test procedure validates that investigation actions are systematically recorded with integrity and provenance controls. Mature organizations maintain detailed, tamper-evident investigation logs attributed to individual responders, with the incident lead responsible for comprehensive documentation. The integrity of these records is critical for post-incident reviews, legal proceedings, and regulatory compliance. ServiceNow ticket audit trails provide a baseline, but dedicated evidence management may be needed for complex incidents.",
"sourcePath": "ASSESSMENT_CATALOG/3_Test_Procedures/RS/RS.AN-06.md"
},
"RS.AN-07": {
"title": "RS.AN-07: Incident Data Collection and Integrity Test Procedures",
"markdown": "# RS.AN-07: Incident Data Collection and Integrity Test Procedures\n\n**CSF Subcategory:** RS.AN-07 - Incident data and metadata are collected, and their integrity and provenance are preserved\n\n---\n\n## Test Procedures\n\n1. **Review incident data collection procedures**\n - Obtain documented procedures for collecting incident data and metadata\n - Verify procedures specify data types to collect (logs, network captures, disk images, memory dumps)\n - Confirm procedures address metadata preservation including timestamps, source systems, and collection methods\n - Check that procedures account for volatile data collection priority and sequencing\n\n2. **Examine data collection tooling and capabilities**\n - Review SentinelOne endpoint data collection capabilities for incident response\n - Verify SIEM log aggregation includes all relevant data sources for incident reconstruction\n - Confirm GuardDuty finding metadata is preserved with original context\n - Check that network traffic capture capabilities exist for incident analysis\n\n3. **Validate integrity preservation mechanisms**\n - Verify cryptographic hashing is applied to collected evidence\n - Confirm write-once or tamper-evident storage is used for incident data\n - Review access controls on evidence repositories\n - Check that integrity verification is performed before evidence is used in analysis\n\n4. **Test provenance documentation for collected data**\n - Select a recent incident and trace data collection chain\n - Verify each evidence item has documented source, collection time, collector identity, and method\n - Confirm chain-of-custody records exist for evidence transferred between systems or personnel\n - Check that automated collection tools log their actions and outputs\n\n---\n\n## Evidence Requests\n\n- [ ] Incident data collection procedures and checklists\n- [ ] SentinelOne incident response data collection configuration\n- [ ] SIEM log source inventory and retention configuration\n- [ ] Evidence hashing and integrity verification procedures\n- [ ] Evidence storage access control lists\n- [ ] Sample chain-of-custody documentation from recent incident\n- [ ] Automated collection tool output logs\n\n---\n\n## Notes\n\nThis test procedure validates that incident data and metadata are collected systematically with integrity and provenance controls. The distinction from RS.AN-06 is that this subcategory focuses on the raw data and metadata collected as evidence, while RS.AN-06 addresses the recording of investigation actions themselves. Mature organizations automate evidence collection where possible, apply cryptographic integrity verification, and maintain detailed provenance records. The quality of collected data directly impacts the effectiveness of root cause analysis under RS.AN-03.",
"markdown": "# RS.AN-07: Incident Data Collection and Integrity Test Procedures\n\n**CSF Subcategory:** RS.AN-07 - Incident data and metadata are collected, and their integrity and provenance are preserved\n\n---\n\n## Test Procedures\n\n1. **Review incident data collection procedures**\n - Obtain documented procedures for collecting incident data and metadata\n - Verify procedures specify data types to collect (logs, network captures, disk images, memory dumps)\n - Confirm procedures address metadata preservation including timestamps, source systems, and collection methods\n - Check that procedures account for volatile data collection priority and sequencing\n\n2. **Examine data collection tooling and capabilities**\n - Review SentinelOne endpoint data collection capabilities for incident response\n - Verify SIEM log aggregation includes all relevant data sources for incident reconstruction\n - Confirm GuardDuty finding metadata is preserved with original context\n - Check that network traffic capture capabilities exist for incident analysis\n\n3. **Validate integrity preservation mechanisms**\n - Verify cryptographic hashing is applied to collected evidence\n - Confirm write-once or tamper-evident storage is used for incident data\n - Review access controls on evidence repositories\n - Check that integrity verification is performed before evidence is used in analysis\n\n4. **Test provenance documentation for collected data**\n - Select a recent incident and trace data collection chain\n - Verify each evidence item has documented source, collection time, collector identity, and method\n - Confirm chain-of-custody records exist for evidence transferred between systems or personnel\n - Check that automated collection tools log their actions and outputs\n\n---\n\n## Evidence Requests\n\n- [ ] Incident data collection procedures and checklists\n- [ ] SentinelOne incident response data collection configuration\n- [ ] SIEM log source inventory and retention configuration\n- [ ] Evidence hashing and integrity verification procedures\n- [ ] Evidence storage access control lists\n- [ ] Sample chain-of-custody documentation from recent incident\n- [ ] Automated collection tool output logs\n- [ ] [Evidence Preservation Guide](https://github.com/CPAtoCybersecurity/csf_profile/blob/main/ASSESSMENT_CATALOG/5_Artifacts/Procedures/PROC-evidence-preservation-guide.md) (ALMA-SOP-2025-010b)\n\n---\n\n## Notes\n\nThis test procedure validates that incident data and metadata are collected systematically with integrity and provenance controls. The distinction from RS.AN-06 is that this subcategory focuses on the raw data and metadata collected as evidence, while RS.AN-06 addresses the recording of investigation actions themselves. Mature organizations automate evidence collection where possible, apply cryptographic integrity verification, and maintain detailed provenance records. The quality of collected data directly impacts the effectiveness of root cause analysis under RS.AN-03.",
"sourcePath": "ASSESSMENT_CATALOG/3_Test_Procedures/RS/RS.AN-07.md"
},
"RS.AN-08": {
Expand Down
Loading