> For the complete documentation index, see [llms.txt](https://book.ice-wzl.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.ice-wzl.xyz/recon-enumeration/engagement-types.md). # Engagement types (black / grey / white box) | Type | Description | | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Black-box** | Little or no prior knowledge. Tester performs full recon (e.g. external test with only org name, or internal with no IP list). Most realistic to a real attacker; can miss issues that need internal/design context. | | **Grey-box** | Some information provided up front: in-scope IPs/ranges, low-priv credentials, app/network diagrams. Simulates insider or post-breach; less time on recon, more on misconfigs and exploitation. | | **White-box** | Full access to design, source, configs, credentials. Aim is maximum finding coverage; not representative of attacker perspective. | Choose scope and rules of engagement (e.g. no DoS, no phishing) per SOW and get them in writing. *** ## Security Assessment Types | Assessment | Purpose | Key Traits | | ---------------------------- | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Vulnerability Assessment** | Identify and categorize known weaknesses via scanning + validation. Little to no manual exploitation. | Checklist-driven, scanner-heavy, results in remediation plan. Appropriate for all orgs. | | **Penetration Test** | Simulated attack to determine if/how a network can be penetrated. Manual + automated. | Requires signed legal scope, medium-to-high security maturity orgs. Goes beyond scanning into exploitation, lateral movement, post-exploitation. | | **Security Audit** | Externally mandated compliance check (government, industry). | Not voluntary — driven by regulation (PCI DSS, HIPAA, etc.). | | **Bug Bounty** | Public program inviting researchers to find vulns for payment. | Large orgs with high maturity; need a dedicated triage team. Usually no automated scanning allowed. | | **Red Team** | Evasive black-box attack simulation by experienced operators. Goal-oriented (e.g. reach a critical DB). | Only reports the chain that reached the objective, not every finding. | | **Purple Team** | Red + Blue working together. Blue observes/provides input during red team campaigns. | Collaborative; improves detection and response in real-time. | Pentester specializations: **Application** (web apps, APIs, mobile, thick-client, source code review), **Network/Infrastructure** (networking devices, servers, AD, scanners like Nessus alongside manual testing), **Physical** (door bypass, tailgating, vent crawling), **Social Engineering** (phishing, vishing, pretexting). *** ## Vulnerability Assessment vs. Penetration Test * A **VA** goes through a checklist: *Do we meet this standard? Do we have this config?* The assessor runs a vuln scan, validates critical/high/medium findings to rule out false positives, but does **not** pursue priv esc, lateral movement, or post-exploitation. * A **pentest** simulates a real attack. It includes manual techniques beyond what scanners find. Only appropriate after some VAs have been conducted and fixes applied. * They complement each other. Orgs should run VAs continuously and pentests annually or semi-annually. *** ## Compliance Standards | Standard | Scope | Notes | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | | [**PCI DSS**](https://www.pcisecuritystandards.org/pci_security/) | Orgs that store/process/transmit cardholder data (banks, online stores). | Requires internal + external scanning. Cardholder Data Environment (CDE) must be segmented from the regular network. | | [**HIPAA**](https://www.hhs.gov/programs/hipaa/index.html) | Healthcare — protects patient data. | Risk assessment + vulnerability identification required for accreditation. | | [**FISMA**](https://www.cisa.gov/federal-information-security-modernization-act) | U.S. government operations and information. | Requires documented vulnerability management program. | | [**ISO 27001**](https://www.iso.org/isoiec-27001-information-security.html) | International information security management. | Requires quarterly internal + external scans. | *** ## Pentesting Standards | Standard | Focus | | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [**PTES**](http://www.pentest-standard.org/index.php/Main_Page) | Pre-engagement → Intel Gathering → Threat Modeling → Vuln Analysis → Exploitation → Post-Exploitation → Reporting | | [**OSSTMM**](https://www.isecom.org/OSSTMM.3.pdf) | 5 channels: Human Security, Physical Security, Wireless, Telecommunications, Data Networks | | [**NIST Pentest Framework**](https://www.nist.gov/cyberframework) | Planning → Discovery → Attack → Reporting | | [**OWASP**](https://owasp.org) | [WSTG](https://owasp.org/www-project-web-security-testing-guide/) (web), [MSTG](https://owasp.org/www-project-mobile-security-testing-guide/) (mobile), [FSTM](https://github.com/scriptingxss/owasp-fstm) (firmware) | *** ## Key Risk Terminology * **Vulnerability** — a weakness (code, config, process) that could be exploited. Registered via [CVE](https://cve.mitre.org/) and scored with [CVSS](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator). * **Threat** — a process or actor that could exploit a vulnerability. * **Exploit** — code or technique that takes advantage of a vulnerability. Sources: [Exploit-DB](https://exploit-db.com), [Rapid7 DB](https://www.rapid7.com/db/), GitHub. * **Risk** — the possibility of harm from a threat exploiting a vulnerability. Measured by **likelihood × impact**. | | Low Impact | Medium Impact | High Impact | | --------------------- | ---------- | ------------- | ------------ | | **High Likelihood** | Medium (3) | High (4) | Critical (5) | | **Medium Likelihood** | Low (2) | Medium (3) | High (4) | | **Low Likelihood** | Lowest (1) | Low (2) | Medium (3) | *** ## CVSS Scoring [CVSS v3.1 Calculator](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator) — scores range 0–10 based on three metric groups: **Base Metrics** (characteristics of the vuln itself): * *Exploitability*: Attack Vector, Attack Complexity, Privileges Required, User Interaction * *Impact*: Confidentiality, Integrity, Availability (CIA triad) **Temporal Metrics** (change over time): * *Exploit Code Maturity*: Unproven → PoC → Functional → High * *Remediation Level*: Official Fix → Temporary Fix → Workaround → Unavailable * *Report Confidence*: Unknown → Reasonable → Confirmed **Environmental Metrics** (org-specific context): * Modified Base Metrics adjusted by the org's CIA requirements (Not Defined / Low / Medium / High). [Microsoft DREAD](https://en.wikipedia.org/wiki/DREAD_\(risk_assessment_model\)) is a complementary 10-point scale based on: **D**amage Potential, **R**eproducibility, **E**xploitability, **A**ffected Users, **D**iscoverability. *** ## CVE Lifecycle [OVAL](https://oval.mitre.org/) (Open Vulnerability Assessment Language) provides XML-based definitions for detecting vulns without exploitation. Four definition classes: Vulnerability, Compliance, Inventory, Patch. ID format: `oval:org.mitre.oval:obj:1116`. **CVE ID assignment stages:** 1. Confirm the issue is a vulnerability (code exploitable, impacts CIA) and no existing CVE covers it. 2. Contact the affected vendor (good-faith responsible disclosure). 3. If vendor is a CNA, they assign the CVE. Otherwise use a third-party CNA. 4. Fall back to the [CVE Web Form](https://cveform.mitre.org/). 5. Receive confirmation email; provide additional info if requested. 6. CVE ID assigned (not yet public). 7. Public disclosure once all parties are aware. 8. Announce — ensure each CVE maps to a distinct vulnerability. 9. Provide details for the official [NVD](https://nvd.nist.gov/) listing. **Responsible disclosure** means working with the vendor to ensure a patch is available before public announcement, preventing zero-day exploitation. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://book.ice-wzl.xyz/recon-enumeration/engagement-types.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.