NIST SP 800‑115 Technical Guide to Information Security Testing & Assessment

Document Background

SP 800‑115 was developed by NIST’s Computer Security Division to give federal agencies a practical, technology‑neutral framework for evaluating the security posture of their information systems. The document applies to any organization that needs to test whether its security controls are implemented correctly and operating as intended (NIST, 2008, Section 1.1).

Unlike many NIST publications that prescribe what controls to implement (such as SP 800‑53), SP 800‑115 focuses on how to verify that those controls actually work. It is the testing companion to the broader risk management framework. For students in Rolling Thunder Security, this document provides the conceptual foundation for the hands‑on penetration testing techniques covered in Rolling Thunder Security 471.

Assessment vs. Testing vs. Examination

SP 800‑115 draws careful distinctions between terms that are often used interchangeably in casual conversation. Understanding these distinctions is essential because they determine the scope, risk level, and authorization requirements of any security evaluation (NIST, 2008, Chapter 2).

Assessment

An assessment is the broadest term. It refers to the entire process of determining the security posture of a system, including reviewing documentation, interviewing personnel, examining configurations, and actively testing defenses. An assessment uses one or more of the techniques described in the document. Think of it as the umbrella under which all other activities fall.

Testing

Testing involves hands‑on interaction with systems and networks to identify vulnerabilities. This is the active component: port scanning, vulnerability scanning, penetration testing, password cracking, and social engineering. Testing carries inherent risk because the assessor is directly interacting with production systems.

Examination

Examination is the passive, documentation‑focused side. It includes reviewing system logs, firewall rule sets, configuration files, policies, and procedures. Examination does not involve active probing of systems and therefore carries minimal operational risk.

A fourth activity, the interview, complements both testing and examination. Interviews with system administrators, developers, and end users help assessors understand how policies are actually implemented in practice, which often differs from what the documentation describes.

The Three Technique Categories

SP 800‑115 organizes all assessment techniques into three broad categories. Each category builds on the previous one, moving from passive analysis toward active exploitation (NIST, 2008, Chapters 3–5).

The Review category is the safest because it involves no direct interaction with production systems. Target Identification and Analysis introduces some risk because scanning tools can occasionally disrupt fragile systems or trigger intrusion detection alerts. Target Vulnerability Validation carries the highest risk because the assessor is actively attempting to break into systems, which can cause service outages, data corruption, or other unintended consequences if not carefully managed.

Testing Phases

When SP 800‑115 discusses active security testing (particularly penetration testing), it describes a four‑phase lifecycle. These phases apply whether the test targets a single web application or an entire enterprise network (NIST, 2008, Chapter 5).

1. Planning

   Define the scope, objectives, rules of engagement, and logistics. Identify which systems are in scope and which are off‑limits. Obtain written authorization from the system owner. Coordinate timing with operations staff to minimize disruption. Planning is the most important phase because errors here cascade into every subsequent step.

2. Discovery

   Gather information about the target environment using both passive and active techniques. Passive discovery includes open‑source intelligence (OSINT) gathering: DNS lookups, WHOIS queries, web searches, and public record analysis. Active discovery includes network scanning, port scanning, service enumeration, and vulnerability scanning. The goal is to build a comprehensive map of the attack surface.

3. Attack

   Attempt to exploit the vulnerabilities identified during discovery. This phase tests whether theoretical weaknesses can be exploited in practice and determines the real‑world impact. The assessor may attempt to escalate privileges, move laterally across the network, exfiltrate test data, or chain multiple vulnerabilities together. Every action is carefully documented, and the tester stays within the boundaries established during planning.

4. Reporting

   Document all findings, including the vulnerabilities discovered, the methods used, the evidence obtained, and prioritized remediation recommendations. The report should be detailed enough for technical staff to reproduce and fix each issue, while also providing an executive summary for management. Reporting transforms raw test results into actionable intelligence.

These four phases are not strictly linear. During the Attack phase, the assessor may discover new targets and cycle back to Discovery. Similarly, findings from one system may prompt additional Planning to expand the scope. The process is iterative, and experienced testers move fluidly between phases as the engagement unfolds.

Planning and Rules of Engagement

SP 800‑115 devotes significant attention to the planning phase because poor planning is the leading cause of assessment failures: missed vulnerabilities, system outages, legal disputes, and wasted resources (NIST, 2008, Section 5.1).

Written Authorization

No testing begins without explicit, written authorization from the system owner. This is not a formality. Without documented permission, even well‑intentioned security testing can violate the Computer Fraud and Abuse Act (CFAA) and similar laws. The authorization document specifies exactly what the assessor is allowed to do, which systems can be tested, and during what time windows.

Rules of Engagement

The rules of engagement (ROE) define the boundaries of the assessment. They specify:

1. Scope and boundaries

   Which IP addresses, applications, and physical locations are in scope. Which systems are explicitly excluded (for example, production databases containing real patient data).

2. Permitted techniques

   Whether social engineering is allowed. Whether denial‑of‑service testing is permitted. Whether the tester may attempt physical access. Each technique carries different risks and requires specific authorization.

3. Communication and escalation

   Who to contact if a critical vulnerability is found. Who to call if testing causes an unintended outage. How to handle the discovery of evidence of a real (non‑simulated) compromise during testing.

4. Data handling

   How sensitive data encountered during testing will be stored, protected, and destroyed. Test data, screenshots, and credential files must be treated with the same care as the production data they represent.

Why It Still Matters

SP 800‑115 was published in 2008, which makes it one of the oldest active publications in the NIST 800 series. Students sometimes question whether a document from the era of Windows XP and Internet Explorer 7 can still be relevant. The answer is yes, and for several important reasons (NIST, 2008).

The methodology is technology‑neutral. SP 800‑115 does not tell you which scanning tool to use or which exploits to run. It describes categories of techniques and phases of testing. Whether you are scanning with Nmap in 2008 or running automated cloud security assessments in 2026, you are still performing target identification and analysis. The tools change; the methodology does not.

It has not been superseded. NIST has not published a replacement document. SP 800‑115 remains the current, authoritative reference for security testing methodology. It is cited in NIST’s Risk Management Framework (SP 800‑37), in the security assessment procedures (SP 800‑53A), and in countless agency security programs.

Industry frameworks reference it. The Penetration Testing Execution Standard (PTES), the OWASP Testing Guide, and the CREST examination syllabus all align with or reference SP 800‑115’s testing phases. Understanding this document gives you a common language shared by the entire security testing community.

It defines the professional vocabulary. Terms like “rules of engagement,” “target identification,” and “vulnerability validation” are not just NIST jargon. They are the standard terminology used in contracts, statements of work, and job descriptions throughout the cybersecurity industry. Learning SP 800‑115’s vocabulary is learning the language of the profession.

Citing This Document (APA 7)

SP 800‑115 is cited as a group‑author technical report. The issuing agency (NIST) serves as the author, the SP number is the report identifier, and the parent department (U.S. Department of Commerce) is the publisher. Because the National Institute of Standards and Technology has a widely recognized abbreviation, APA 7 allows it to be introduced on first use and reused thereafter.

Remember that APA 7 does not require page numbers for paraphrased material from technical documents; use the section or chapter number instead. The title of a standalone report is italicized, but the publication number in parentheses is not.