# Penetration Testing
Penetration testing is the practice of simulating real-world attacks against an organization's systems, networks, and applications to identify exploitable vulnerabilities before actual adversaries do. A penetration tester (pen tester) uses the same tools, techniques, and procedures (TTPs) that attackers use, but operates under a defined scope, with legal authorization, and reports the findings to the organization for remediation.
Penetration testing is not vulnerability scanning. A vulnerability scanner identifies known vulnerabilities by matching system configurations and software versions against a database of known issues. It reports potential weaknesses. A penetration test goes further: it attempts to exploit those weaknesses, chain them together, and demonstrate the actual impact of a successful attack. The difference is the difference between identifying a lock that might be pickable and actually picking it.
The value of penetration testing is proof. A vulnerability scan says "this lock might be weak." A penetration test says "I opened this lock, walked through the door, accessed the file server, and exfiltrated the CEO's email archive. Here is the evidence."
External penetration test. Tests the organization's internet-facing attack surface from the perspective of an external attacker with no prior access. Targets include web applications, API endpoints, email gateways, VPN concentrators, DNS infrastructure, and any other service reachable from the internet. This is the test that answers: "What can an attacker on the internet reach and exploit?"
Internal penetration test. Tests the organization's internal network from the perspective of an attacker who has gained initial access (through phishing, a compromised endpoint, or a rogue insider). Targets include Active Directory, internal applications, file shares, network segmentation boundaries, and privileged access paths. This test answers: "Once inside, how far can an attacker go?"
Web application penetration test. Focuses specifically on a web application or set of applications. Tests for OWASP Top 10 vulnerabilities (injection, broken authentication, sensitive data exposure, security misconfiguration, etc.) and application-specific logic flaws that automated scanners cannot detect. Business logic vulnerabilities (manipulating a checkout flow to change prices, accessing another user's data by modifying a URL parameter) are found by pen testers, not by scanners.
Wireless penetration test. Tests the security of wireless networks: WPA/WPA2/WPA3 configurations, rogue access points, guest network isolation, and wireless client security. In organizations with significant wireless infrastructure, this test identifies whether an attacker in the parking lot can access the corporate network.
Social engineering test. Tests the human element: phishing campaigns, vishing (voice phishing), physical security (tailgating, badge cloning, dumpster diving). This test answers: "Can an attacker manipulate your people into granting access that your technical controls would deny?"
Red team assessment. A red team assessment is an adversarial simulation that combines multiple attack vectors (external, internal, social engineering, physical) to achieve a specific objective (access the CEO's email, exfiltrate customer data, deploy ransomware in a test environment). Red teams operate with minimal scope restrictions and maximum stealth, simulating a real adversary as closely as possible. The objective is not to find all vulnerabilities. It is to demonstrate whether a motivated, skilled attacker can achieve a specific outcome against the organization's defenses.
A structured penetration test follows five phases:
Scoping and rules of engagement. Define what is in scope (which systems, networks, and applications), what is out of scope (production systems that cannot tolerate disruption, third-party systems without authorization), what techniques are authorized (is social engineering allowed? physical intrusion?), and what the reporting requirements are. The rules of engagement are a legal document. Testing without proper authorization is a criminal offense regardless of intent.
Reconnaissance. Gather information about the target: DNS records, IP ranges, technology stack, employee names and roles (from LinkedIn, the company website), email formats, exposed credentials in breach databases, and any other publicly available information. Passive reconnaissance gathers information without touching the target. Active reconnaissance (port scanning, service enumeration) directly interacts with the target's systems.
Exploitation. Attempt to exploit identified vulnerabilities. This includes exploiting software vulnerabilities (unpatched services, known CVEs with public exploit code), misconfiguration exploitation (default credentials, open management interfaces, misconfigured cloud permissions), credential attacks (password spraying, credential stuffing, Kerberoasting), and social engineering (if in scope). Each successful exploitation is documented with evidence.
Post-exploitation. After gaining initial access, determine what the access enables. Can the tester escalate privileges? Move laterally to other systems? Access sensitive data? Reach the domain controller? Post-exploitation demonstrates the real-world impact of the initial vulnerability. A SQL injection vulnerability in a web application is a finding. A SQL injection that leads to database access, credential extraction, lateral movement to the Active Directory, and domain administrator compromise is a critical finding that demonstrates organizational risk.
Reporting. Document every finding with evidence, severity rating, business impact, and specific remediation guidance. The report serves two audiences: technical staff who will remediate the findings and executive leadership who need to understand the risk in business terms. A good penetration test report converts technical vulnerabilities into business risk statements that drive investment decisions.
Penetration testing is conducted against established methodologies:
OWASP Testing Guide. The standard for web application penetration testing. Provides a structured checklist of tests organized by vulnerability category.
PTES (Penetration Testing Execution Standard). Defines a complete methodology from pre-engagement through reporting.
NIST SP 800-115. Technical guide to information security testing and assessment, including penetration testing methodology for federal systems.
MITRE ATT&CK. While not a penetration testing methodology per se, ATT&CK provides the taxonomy of adversary techniques that pen testers use to structure their approach and map their findings to real-world threat actor behavior.
Vulnerability scans, configuration audits, and compliance assessments produce findings based on known patterns. They identify what might be wrong. Penetration testing proves what is wrong by demonstrating exploitation. The difference in organizational impact is significant: a vulnerability scan finding that says "this server is missing patch KB5034441" generates a ticket. A penetration test finding that says "I exploited this missing patch to gain SYSTEM access, extracted cached credentials, and used those credentials to access the HR database containing 15,000 employee Social Security numbers" generates an emergency remediation effort and a board briefing.
Individual vulnerabilities are often low or medium severity in isolation. A pen tester discovers that the real risk comes from chaining them: a low-severity information disclosure combined with a medium-severity authentication bypass combined with a medium-severity privilege escalation produces a critical attack path that no individual scan finding would surface. Penetration testing reveals attack chains. Vulnerability scanning reveals individual links.
Multiple compliance frameworks mandate penetration testing:
Penetration testing validates the effectiveness of controls deployed across multiple PDM domains. Does the firewall (SPH) block the exploit? Does the WAF (VSD) detect the injection? Does MFA (IAT) prevent the credential attack? Does the EDR (SPH) alert on the post-exploitation activity? Does the SIEM (TID) correlate the events? A penetration test that triggers no defensive alerts is evidence that the detection and prevention controls are insufficient, regardless of what the vendor dashboards report.
Penetration testing sits in the VSD (Vulnerability and Surface Defense) domain of the Planetary Defense Model. It is the verification mechanism that proves whether CSR (Continuous Surface Reduction) is working. "Every surface you expose is a surface we eliminate." Penetration testing answers: did we eliminate it, or do we just think we did?
Three TOP missions are penetration testing operations:
Combined, these three missions represent 112 hours of testing, nearly 29% of all VSD operational hours. CDA invests this proportion deliberately. A vulnerability management program that has never been validated by adversarial testing is a theory. A program validated by a red team exercise that found no critical path to crown jewel assets is a defense.
The interaction with adjacent domains is direct. A penetration test that compromises an endpoint tests SPH (did the endpoint hardening hold?). A test that uses stolen credentials tests IAT (did MFA stop the attack?). A test that triggers no alerts tests TID (does the detection stack work?). A test that reaches sensitive data tests DPS (was the data encrypted, and did the encryption key management prevent access?). Penetration testing is VSD's primary tool, but its results inform every domain.
CDA approaches penetration testing differently from conventional firms in one way: we do not treat it as a standalone engagement. Conventional pen test firms conduct annual tests, deliver a report, and leave. CDA's penetration testing missions are embedded in the campaign lifecycle. The findings from VSD-D01 and VSD-D02 feed directly into remediation missions (VSD-B01, VSD-B03) and are verified in the next test cycle. The pen test is not a snapshot. It is part of a continuous reduction loop.
Word count: 2,081