# CA-08 Penetration Testing

NIST SP 800-53 control. Family: CA Security Assessment and Authorization. Function: detective. Baselines: high. Mapping licence: CC BY-SA 4.0.

Statement: Conduct penetration testing [Assignment: organization-defined frequency] on [Assignment: organization-defined systems or system components].
Guidance: Penetration testing is a specialized type of assessment conducted on systems or individual system components to identify vulnerabilities that could be exploited by adversaries. Penetration testing goes beyond automated vulnerability scanning and is conducted by agents and teams with demonstrable skills and experience that include technical expertise in network, operating system, and/or application level security. Penetration testing can be used to validate vulnerabilities or determine the degree of penetration resistance of systems to adversaries within specified constraints. Such constraints include time, resources, and skills. Penetration testing attempts to duplicate the actions of adversaries and provides a more in-depth analysis of security- and privacy-related weaknesses or deficiencies. Penetration testing is especially important when organizations are transitioning from older technologies to newer technologies (e.g., transitioning from IPv4 to IPv6 network protocols). Organizations can use the results of vulnerability analyses to support penetration testing activities. Penetration testing can be conducted internally or externally on the hardware, software, or firmware components of a system and can exercise both physical and technical controls. A standard method for penetration testing includes a pretest analysis based on full knowledge of the system, pretest identification of potential vulnerabilities based on the pretest analysis, and testing designed to determine the exploitability of vulnerabilities. All parties agree to the rules of engagement before commencing penetration testing scenarios. Organizations correlate the rules of engagement for the penetration tests with the tools, techniques, and procedures that are anticipated to be employed by adversaries. Penetration testing may result in the exposure of information that is protected by laws or regulations, to individuals conducting the testing. Rules of engagement, contracts, or other appropriate mechanisms can be used to communicate expectations for how to protect this information. Risk assessments guide the decisions on the level of independence required for the personnel conducting penetration testing.

## Enhancements (3)
- CA-08(01) Independent Penetration Testing Agent or Team. Baselines: high
- CA-08(02) Red Team Exercises
- CA-08(03) Facility Penetration Testing
Each enhancement's statement: /api/v1/controls/CA-08?fields=enhancements

## Patterns that use it (7)
- Critical (3): SP-035 Offensive Security Testing; SP-051 Tokenised Asset Security Architecture (draft); SP-053 Zero-Knowledge Proof Architecture (draft)
- Important (3): SP-012 Secure Software Development Lifecycle; SP-043 Security Metrics and Measurement; SP-054 CBDC and Digital Currency Infrastructure (draft)
- Standard (1): SP-038 Vulnerability Management and Patching

## Clauses by framework (58 frameworks)
- iso_27001_2022: A.8.34. OSA's own, not in NIST's crosswalk: A.8.34
- iso_27002_2022: 8.34
- cobit_2019: MEA04
- pci_dss_v4: 11.4
- nist_csf_2: ID.IM-01, ID.IM-02, ID.IM-03, ID.RA-01
- cis_controls_v8: CIS 16.13, CIS 18, CIS 18.1, CIS 18.2, CIS 18.4, CIS 18.5
- nis2: Art. 21(2)(f)
- apra_cps_234: Para 22-23, Para 24
- mas_trm: 13
- pra_op_resilience: SS1/21-6.1
- dora: Art.24(1), Art.25(1), Art.26
- bio2: 8.34
- rbi_csf: Annex1.18, ITGRCA.26
- lgpd_bcb: BCB.Art.10
- hkma_tme1: TME1.7.4
- dnb_good_practice: DNB.16.1, DNB.16.5, DNB.22.1
- cra: CRA.I.2a, CRA.II.3
- swift_cscf: SWIFT.7.3A
- cbuae: CR-10
- nca_ecc: 1-8, 2-11
- qatar_nia: OS
- sama_csf: 1.9
- bog_cisd: CISD-X
- bom_ctrm: 4.3
- cbe_csf: OVM-3
- cbn_csf: Part2.3, Part3.8
- sa_js2: JS2-7.7
- bot_cyber: Ch3.2
- cpmi_pfmi: CG.TE
- eba_ict: 3.4.6
- ecb_croe: CROE.2.6.1, CROE.2.6.2
- ffiec_is: II.A.2, IV.A, IV.A.1, IV.A.2, IV.A.3
- iosco_cyber: SA-3, TEST-1, TEST-2, TEST-4
- nydfs_500: 500.5
- sebi_cscrf: DE.VA, VAPT
- cmmc_2: CA, RA
- nerc_cip: CIP-010-4
- nrc_73_54: RG5.71-C-CA
- tsa_psd: SD-1 Sec 3, SD-2 Sec G
- api_1164: Sec 15
- iaea_nss: Sec 11
- fips_140: FIPS 140-3 §7.10
- cbest: CBEST.3, CBEST.4
- tiber_eu: TIBER.PREP, TIBER.RT
- common_criteria: CC Part 3 — SAR, CEM
- isae_3402: Clause 6
- fda_21_cfr_11: §11.300(e)
- fda_cyber: CRA-1, ST-2
- hitrust_csf: 06.c
- iso_27799: 18.3, 18.4
- lloyds_ms: MS8.11, MS9.2
- naic_ds: 4-monitoring
- nhs_dspt: NDG-9.8
- pra_ss1_23: P4.2, P5.4
- csa_ccm_v4: AA-02, AIS-05, TVM-06
- csa_aicm: A&A-02, AIS-05, AIS-13, MDS-03, TVM-06, TVM-12
- ccss_v9: 1.02.7, 2.01.2, 2.01.3, 2.03.2
- bssc: GSP-08, GSP-15, TIS-02
OSA's mapping for iso_27001_2022 and nist_csf_2 takes NIST's published crosswalk as its base. A clause not marked as OSA's own is in that crosswalk.

## More
- This control as JSON, with guidance and ATT&CK techniques: /api/v1/controls/CA-08
- Clauses only: /api/v1/controls/CA-08?fields=mappings
- Page for people: /controls/ca-08/
- Found an error? Open an issue at https://github.com/opensecurityarchitecture/osa-data/issues with the id, what OSA says and what the source says.