diff --git a/standard/3_Human_Oversight/Implementation_Guide.md b/standard/3_Human_Oversight/Implementation_Guide.md index 53cff42..5166a57 100644 --- a/standard/3_Human_Oversight/Implementation_Guide.md +++ b/standard/3_Human_Oversight/Implementation_Guide.md @@ -331,6 +331,8 @@ Competency MUST be validated through practical assessment (not just attendance). **Shift Handoff Checklist:** +The [Shift Handoff Template](../appendix/Shift_Handoff_Template.md) provides an optional record structure for preserving this context with the engagement audit trail. + The outgoing operator MUST complete the following before transferring authority: 1. [ ] Confirm engagement status (active/paused/completing) with incoming operator diff --git a/standard/3_Human_Oversight/README.md b/standard/3_Human_Oversight/README.md index f4ef47b..4c353cd 100644 --- a/standard/3_Human_Oversight/README.md +++ b/standard/3_Human_Oversight/README.md @@ -916,6 +916,8 @@ For platforms operating in continuous or always-on mode, the platform SHOULD imp Approval queues SHOULD enforce shift-awareness so that approvals granted by an outgoing operator for future actions are flagged for incoming operator review. +> **Implementation aid:** The [Shift Handoff Template](../appendix/Shift_Handoff_Template.md) provides an informative record format for transferring engagement state, pending approvals, open escalations, suppression-rule status, and kill-switch authority between operators. + ### Verification 1. Shift handoff procedure is documented and includes engagement state, pending approvals, and active escalations diff --git a/standard/Getting_Started.md b/standard/Getting_Started.md index f237ab2..7130b80 100644 --- a/standard/Getting_Started.md +++ b/standard/Getting_Started.md @@ -72,7 +72,8 @@ Depending on your role: | [Cross-Domain Integration](appendix/Cross_Domain_Integration.md) | Informative | Cross-domain trigger mappings and dependency analysis | | [Testing Phase Mapping](appendix/Testing_Phase_Mapping.md) | Informative | Requirements mapped to pentesting lifecycle phases | | [Evidence Request Checklist](appendix/Evidence_Request_Checklist.md) | Informative | Lightweight checklist of artifacts customers and reviewers can request | -| [Human Review Record Template](appendix/Human_Review_Record_Template.md) | Informative | Illustrative reviewer approval record for critical findings | +| [Human Review Record Template](appendix/Human_Review_Record_Template.md) | Informative | Illustrative template for documenting reviewer approval of critical findings | +| [Shift Handoff Template](appendix/Shift_Handoff_Template.md) | Informative | Template for documenting operator shift handoffs, pending approvals, safety signals, and authority transfer | | [Conformance Claim Schema](appendix/Conformance_Claim_Schema.md) | Informative | Illustrative machine-readable schema for structured conformance claims | | [Conformance Claim Template](appendix/Conformance_Claim_Template.md) | Informative | Optional template for platform operators documenting conformance | | [Evidence Package Manifest](appendix/Evidence_Package_Manifest.md) | Informative | Illustrative manifest for finding evidence, provenance, and downstream handoff | @@ -84,7 +85,7 @@ Depending on your role: ## Common Questions **Q: Do I need to implement all 173 requirements?** -No. Start with Tier 1 (72 requirements). Tier 2 and Tier 3 add requirements progressively for cumulative totals of 157 and 173. An additional 14 advisory practices live in the [Advisory Requirements appendix](appendix/Advisory_Requirements.md) under the `APTS--A0x` identifier pattern; advisory practices are not required for conformance at any tier. See [Introduction: Compliance Tiers](Introduction.md#compliance-tiers) for details. +No. Start with Tier 1 (72 requirements). Tier 2 and Tier 3 add requirements progressively for cumulative totals of 157 and 173. An additional 15 advisory practices live in the [Advisory Requirements appendix](appendix/Advisory_Requirements.md) under the `APTS--A0x` identifier pattern; advisory practices are not required for conformance at any tier. See [Introduction: Compliance Tiers](Introduction.md#compliance-tiers) for details. **Q: What if my platform meets most but not all Tier 1 requirements?** APTS does not award partial credit. A platform must meet 100% of requirements for its claimed tier. Address gaps before claiming a tier. diff --git a/standard/README.md b/standard/README.md index 429f27d..0c1610c 100644 --- a/standard/README.md +++ b/standard/README.md @@ -1,6 +1,6 @@ # OWASP Autonomous Penetration Testing Standard -This is the full OWASP Autonomous Penetration Testing Standard. It defines 173 tier-required requirements across 8 domains (plus 14 advisory practices in the [Advisory Requirements appendix](appendix/Advisory_Requirements.md)) that autonomous penetration testing platforms must meet to operate safely, transparently, and within defined boundaries, whether delivered by vendors, operated as a service, or built in-house by enterprise security teams. +This is the full OWASP Autonomous Penetration Testing Standard. It defines 173 tier-required requirements across 8 domains (plus 15 advisory practices in the [Advisory Requirements appendix](appendix/Advisory_Requirements.md)) that autonomous penetration testing platforms must meet to operate safely, transparently, and within defined boundaries, whether delivered by vendors, operated as a service, or built in-house by enterprise security teams. ## Getting Started @@ -43,6 +43,7 @@ The [appendices](./appendix/) provide cross-cutting resources: checklists, compl | [Conformance Claim Example](./appendix/examples/Conformance_Claim_Example.md) | Fictional completed example showing how an operator might document an APTS conformance claim | | [Evidence Request Checklist](./appendix/Evidence_Request_Checklist.md) | Simple artifact checklist for customer and reviewer evidence requests | | [Human Review Record Template](./appendix/Human_Review_Record_Template.md) | Illustrative template for documenting reviewer approval of critical findings | +| [Shift Handoff Template](./appendix/Shift_Handoff_Template.md) | Informative template for documenting operator shift handoffs, pending approvals, safety signals, and authority transfer | | [Advisory Requirements](./appendix/Advisory_Requirements.md) | Non-mandatory practices for enhanced assurance | | [Incident Response Integration](./appendix/Incident_Response_Integration.md) | Unified incident response workflow across domains | diff --git a/standard/appendix/Shift_Handoff_Template.md b/standard/appendix/Shift_Handoff_Template.md new file mode 100644 index 0000000..07efb20 --- /dev/null +++ b/standard/appendix/Shift_Handoff_Template.md @@ -0,0 +1,145 @@ +# Shift Handoff Template + +This appendix is informative and does not create or modify APTS requirements. + +## Purpose + +Use this template to document operational continuity when responsibility for an autonomous penetration testing engagement transfers from one operator or shift to another. It supports APTS-HO-019 by making active engagement state, pending decisions, safety signals, and authority changes explicit before the incoming operator allows testing to continue. + +The template is intentionally lightweight. Teams may implement it as a ticket form, runbook section, dashboard workflow, or signed record in the platform, provided the handoff record is preserved with the engagement audit trail. + +## When to Use This Template + +Use a handoff record when any of the following occur: + +- an always-on or long-running engagement crosses an operator shift boundary +- kill-switch authority, approval authority, or escalation responsibility changes hands +- approvals granted by an outgoing operator may be acted on by an incoming operator +- active alert suppressions, scope exceptions, or safety concerns remain open +- customer-impact, incident-response, or autonomy-downgrade decisions are pending + +## Handoff Metadata + +| Field | Example / guidance | +|-------|--------------------| +| Handoff ID | `handoff-2026-04-18-day-to-night` | +| Engagement ID | Customer, workspace, or engagement identifier | +| Platform / environment | Production service, customer tenant, or internal deployment | +| Outgoing operator | Name, role ID, and contact method | +| Incoming operator | Name, role ID, and contact method | +| Handoff time | Timestamp with timezone | +| Covered operating window | Start and end time for the incoming shift | +| Current testing phase | Reconnaissance, validation, exploitation, reporting, cleanup, or paused | +| Applicable Rules of Engagement | RoE document ID and version | +| Authority Delegation Matrix reference | Matrix ID/version and applicable role row | +| Audit log reference | Link or identifier for the handoff record in the audit trail | + +## Current Engagement State + +| Field | Status / notes | +|-------|----------------| +| Engagement status | active / paused / completing / incident-response / customer hold | +| Current autonomy level | L1 / L2 / L3 / L4 and reason for current level | +| Active target set | Targets currently in scope for automated or operator-directed action | +| Excluded or paused targets | Assets excluded, paused, or awaiting customer clarification | +| Current rate limits / blast-radius limits | Any temporary throttles or extra safeguards in force | +| Active safety controls | Kill switch, pause, rollback, health monitoring, watchdogs | +| Current kill-switch authority | Primary, secondary, emergency authority, and escalation path | +| Customer contacts on duty | Customer or stakeholder contacts for escalation during the shift | + +## Pending Operator Decisions + +Use this section to prevent stale approvals from silently carrying across shifts. + +| Decision ID | Action / context | Requested by | Current status | Expiry | Incoming-shift action | +|-------------|------------------|--------------|----------------|--------|-----------------------| +| `approval-001` | Example: high-impact payload validation against target group A | Operator or system | pending / approved / rejected / expired | Time and timezone | re-review / re-request / cancel / proceed | + +For each pending item, record whether the incoming operator must re-approve the action before execution. Critical or irreversible actions should require synchronous confirmation rather than inherited approval. + +## Open Escalations and Safety Signals + +| Signal | Requirement area | Current response | Owner | Required next action | +|--------|------------------|------------------|-------|----------------------| +| Scope anomaly | SE / HO / AL | paused affected action | incoming operator | confirm scope before resuming | +| Suppression rule active | HO-019 | review due during next shift | incoming operator | justify, expire, or remove suppression | +| Customer-impact warning | SC / HO / AL | monitoring increased | escalation lead | notify if threshold crossed | +| Model/tool behavior anomaly | AL / MR / TP | autonomy capped | platform owner | investigate before re-escalation | + +## Desensitization Monitoring + +Use this section to make alert-fatigue and response-time degradation visible to the incoming shift. The handoff should capture whether operators are still responding to safety signals promptly or whether suppressions, repeated alerts, or delayed acknowledgments indicate reduced monitoring effectiveness. + +| Indicator | Current trend / evidence | Outgoing-shift notes | Incoming-shift action | +|-----------|--------------------------|----------------------|-----------------------| +| Safety-alert response time | Stable / increasing / decreasing; include dashboard or log reference | Note delayed responses, missed pages, or escalation delays | continue monitoring / escalate / restore notification channel | +| Alert acknowledgment rate | Percentage or count acknowledged during outgoing shift | Note unacknowledged alerts or repeated snoozes | review backlog / assign owner / remove stale suppression | +| Alert-fatigue indicators | Repeated dismissals, muted channels, duplicate alerts, or operator overload | Note whether fatigue may affect critical-signal handling | reduce noise / escalate staffing / lower autonomy level | +| Suppression pressure | New, extended, or contested suppression rules | Note justification, expiry, and safety impact | expire / re-justify / remove before resuming | + +## Active Findings and Evidence + +| Item | Status / notes | +|------|----------------| +| Findings under validation | IDs, affected targets, confidence, pending reviewer actions | +| Evidence packages in progress | Manifest IDs, hash status, redaction status, storage location | +| Customer-visible findings pending review | Items that may require notification or report inclusion | +| Cleanup / rollback state | Reversible actions that still need verification | +| Evidence integrity concerns | Missing hashes, timestamp gaps, custody changes, or export issues | + +## Tool and Connector State + +Document externally connected tools so the incoming operator understands which capabilities remain active. + +| Connector / tool | Capability | Credential scope | Current state | Required incoming action | +|------------------|------------|------------------|---------------|--------------------------| +| Browser agent | Web interaction | Engagement-scoped account | enabled / disabled / paused | review session state | +| Scanner | Network testing | Target-scoped token | enabled / disabled / paused | confirm rate limits | +| Shell or runner | Code execution | Sandbox-scoped identity | enabled / disabled / paused | confirm boundary controls | +| Data connector | Evidence retrieval | Read-only evidence store | enabled / disabled / paused | confirm audit logging | + +Include any emergency revocations, temporary credentials, or connector-specific approval constraints that apply during the incoming shift. + +## Incoming Operator Acceptance Checklist + +The incoming operator should complete this checklist before permitting queued or autonomous actions to continue. + +- [ ] I reviewed the active scope, exclusions, and paused targets. +- [ ] I reviewed current autonomy level and any temporary autonomy caps. +- [ ] I can activate the applicable kill switch and understand the escalation path. +- [ ] I reviewed all pending approvals and identified any that require re-approval. +- [ ] I reviewed active suppressions and their expiry or re-justification deadlines. +- [ ] I reviewed desensitization indicators, including response-time trends and alert acknowledgment rates. +- [ ] I reviewed open safety signals, incidents, or customer-impact concerns. +- [ ] I reviewed active tools/connectors and any elevated credential state. +- [ ] I confirmed access to dashboards, logs, notifications, and customer contacts. +- [ ] I accepted responsibility for the incoming operating window in the audit trail. + +## Sign-Off + +| Role | Name / ID | Timestamp | Notes | +|------|-----------|-----------|-------| +| Outgoing operator | | | Handoff prepared and transferred | +| Incoming operator | | | Handoff reviewed and accepted | +| Escalation authority, if applicable | | | Required only when authority changes or open escalations exist | + +## Reviewer Questions + +- Does the handoff record identify the current operator, kill-switch authority, and escalation path? +- Are pending approvals expired, re-requested, or explicitly accepted by the incoming operator? +- Are active alert suppressions justified with review dates so suppression drift is visible? +- Are response-time trends, alert acknowledgment rates, and alert-fatigue indicators visible to the incoming operator? +- Are customer-impact warnings, incidents, and autonomy-downgrade considerations carried into the next shift? +- Can the handoff record be reconciled against the immutable audit trail and approval history? + +## Related Requirements and Appendices + +- APTS-HO-004: Authority Delegation Matrix +- APTS-HO-005: Delegation Chain-of-Custody and Decision Audit Trail +- APTS-HO-009: Multi-Operator Kill Switch Authority and Handoff +- APTS-HO-015: Real-Time Activity Monitoring and Multi-Channel Notification +- APTS-HO-019: 24/7 Operational Continuity and Shift Handoff +- APTS-AL-025: Autonomy Level Authorization, Transition, and Reauthorization +- [Authority Delegation Matrix Template](Authority_Delegation_Matrix_Template.md) +- [Rules of Engagement Template](Rules_of_Engagement_Template.md) +- [Incident Response Integration](Incident_Response_Integration.md)