DoD Directive (DoDD) 8500.1, "Information Assurance (IA)," is the foundational policy document that establishes the DoD's overarching strategy for IA. The purpose statement within this directive explicitly states that it "Establishes policy and assigns responsibilities...to achieve information assurance (IA) through a defense-in-depth approach that integrates the capabilities of personnel, operations, and technology, and supports the evolution to network centric warfare." This wording directly matches the description provided in the question, identifying it as the correct high-level policy document. While this directive has been superseded, it remains a key historical document within the ISSEP body of knowledge.

A. DoD 8500.2 Information Assurance Implementation: This is an instruction that provides specific procedures and controls for implementing the high-level policy established in DoDD 8500.1, not the policy itself.

B. DoD 8510.1-M DITSCAP: This was the application manual for the DoD Information Technology Security Certification and Accreditation Process (DITSCAP), detailing a specific process, not the overarching IA policy.

C. DoDI 5200.40: This instruction formally established the DITSCAP framework. It is focused specifically on the Certification and Accreditation (C&A) process, which is only one component of the broader IA program.

1. U.S. Department of Defense. (2002

October 24). DoD Directive 8500.1: Information Assurance (IA). Washington

D.C.: DoD Chief Information Officer. Section 2

"PURPOSE

" states the directive's goal is to "achieve information assurance (IA) through a defense-in-depth approach that integrates the capabilities of personnel

operations

and technology

and supports the evolution to network centric warfare."

2. U.S. Department of Defense. (2003

February 6). DoD Instruction 8500.2: Information Assurance (IA) Implementation. Washington

D.C.: DoD Chief Information Officer. Section 2

"PURPOSE

" clarifies that the instruction "implements policy

assigns responsibilities

and prescribes procedures...under DoDD 8500.1."

3. Wilson

I. D. (2005). A Comparative Analysis of the Department of Defense Information Assurance Certification and Accreditation Process (DIACAP) and the National Information Assurance Certification and Accreditation Process (NIACAP) (Master's thesis

Naval Postgraduate School). Chapter II

Section B

"DoD IA Policy

" pp. 9-11. This thesis describes the hierarchy of DoD IA policy

identifying DoDD 8500.1 as the primary policy document and DITSCAP (established by DoDI 5200.40) as the C&A process used to enforce it. (Available via NPS Calhoun institutional repository).

4. U.S. Department of Defense. (1997

December 30). DoD Instruction 5200.40: DoD Information Technology Security Certification and Accreditation Process (DITSCAP). Washington

D.C.: Assistant Secretary of Defense. This document's purpose is to establish the C&A process

not the entire IA policy framework.

According to the Committee on National Security Systems (CNSS) issuance system, a CNSS Directive (CNSSD) is the specific type of document used to establish or describe CNSS policy and programs. Directives are foundational issuances that provide authority or assign responsibilities to U.S. Government departments and agencies concerning the security of National Security Systems (NSS). They serve as the primary mechanism for the CNSS to enact its policies and define the scope of its programs, making them the authoritative source for these matters.

A. Instructions: CNSS Instructions (CNSSI) provide mandatory guidance for the implementation of established policies and directives, not for their creation.

C. Policies: While CNSS Policies (CNSSP) contain mandatory direction, the Directive (CNSSD) is the specific issuance type that formally establishes the policy or program itself.

D. Advisory memoranda: CNSS Advisory Memoranda (CNSSAM) provide temporary guidance, information, or clarification on existing issuances, not the establishment of new, lasting policy.

1. Committee on National Security Systems (CNSS). (2012

June). National Instruction on Committee on National Security Systems (CNSS) Issuance System (CNSSI No. 1001). Section 4.a

"CNSS Directives (CNSSD)

" Page 2. "CNSSDs establish or describe CNSS policy and programs

provide authority

or assign responsibilities."

2. Wilson

M.

& Toth

P. (2009). Executive Guide to Information Security: The Personal Security Desk Reference for Executives. Syngress Publishing. Chapter 4

"Federal Information Security Laws

Regulations

and Guidelines

" Page 101. (Note: While a book

it directly cites and explains the function of official government documents like CNSS Directives in an academic context). The text describes how CNSS Directives establish policy for national security systems.

The risk mitigation phase, which aligns with the "Risk Response" step in foundational risk management models, focuses on deciding how to address identified risks and putting that decision into action. This involves first agreeing on a suitable strategy (e.g., mitigate, transfer, accept, avoid) based on the risk assessment. Following this strategic decision, a detailed mitigation plan is documented and subsequently implemented. This plan outlines the specific controls, actions, responsibilities, and timelines required to reduce the risk to an acceptable level. In the context of the NIST RMF, these activities are captured within the Plan of Action and Milestones (POA&M).

B. Evaluate mitigation progress and plan next assessment.

This activity is part of the risk monitoring phase (e.g., NIST RMF Step 6: Monitor), which occurs after the mitigation plan has been implemented to ensure controls remain effective.

C. Identify threats, vulnerabilities, and controls that will be evaluated.

This is a core activity of the risk assessment phase (e.g., NIST RMF Step 2: Select and Step 4: Assess), which must be completed before mitigation planning can begin.

1. NIST Special Publication 800-39

Managing Information Security Risk: Organization

Mission

and Information System View.

Page 13

Section 2.3

"RISK RESPONSE": "Once risk is determined from the risk assessment

organizations develop and implement a course of action to respond to that risk... The purpose of the risk response step is to identify

evaluate

and implement the appropriate course(s) of action." This supports selecting a strategy (A) and implementing a plan (D).

Page 13

Section 2.3

"RISK MONITORING": "Organizations monitor the implementation and effectiveness of risk responses on an ongoing basis..." This confirms that evaluating progress (B) is a separate

subsequent phase.

2. NIST Special Publication 800-37 Revision 2

Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy.

Page 58

Section 3.5

"TASK A-2: DETERMINE RISK": The output of the risk assessment includes "a list of identified risks to be addressed in the risk response phase of the risk management process." This shows that identification (C) precedes mitigation.

Page 81

Appendix F

"PLAN OF ACTION AND MILESTONES": "The plan of action and milestones is a key document in the risk management process... [it] is the primary vehicle for documenting the planned activities to correct weaknesses and deficiencies..." This directly supports the documentation and implementation of a mitigation plan (D).

3. Carnegie Mellon University

Software Engineering Institute (SEI)

Continuous Risk Management Guidebook.

Page 21

Chapter 4

"Mitigation": "Risk mitigation is the process of developing

selecting

and implementing a course of action to reduce risk to an acceptable level... The process begins with the development of risk mitigation plans." This source defines the mitigation phase as including the development of a strategy and the implementation of a plan (A and D).

Committee on National Security Systems Policy No. 200—still commonly cited under its legacy title “NSTISSP No. 200”—is the authoritative national policy entitled “Controlled Access Protection (CAP).” It establishes minimum CAP requirements for telecommunications and automated information systems that handle national-security information. None of the other numbered policies or directives addresses CAP; they pertain to unrelated areas such as crypto-module use, TEMPEST, or information sharing.

A. NSTISSP No. 101 governs the use of Commercial‐off‐the‐Shelf (COTS) cryptographic modules in national-security systems, not CAP requirements.

C. NCSC No. 5 is an NSA technical guideline, not a CNSS policy, and does not set national policy on controlled access protection.

D. CNSSP No. 14 establishes requirements for the release/transfer of national-security information among nations, unrelated to CAP controls.

1. Committee on National Security Systems. “NSTISSP No. 200: National Policy on Controlled Access Protection

” 29 May 2000

pp. 1-2

§§1-2.

2. Committee on National Security Systems. CNSS Instruction 1253

“Security Categorization and Control Selection

” Mar 2012

p. A-4 (lists CAP linkage to Policy 200).

3. University of Maryland Global Campus (UMGC) INFA 620 Course Notes

Week 6: U.S. National IA Policy Framework

slide 12 (summarizes NSTISSP 200 as CAP policy).

4. MIT OpenCourseWare 6.858 “Computer Systems Security

” Lecture 6 Notes

reference table of CNSS/NSTISSP policies (identifies #200 as Controlled Access Protection).

Information Assurance (IA) is the correct term that encompasses the five pillars listed in the question. IA is formally defined as the set of measures intended to protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. This includes providing for the restoration of information systems by incorporating protection, detection, and reaction capabilities. While often used interchangeably with Information Security, IA represents a broader, more comprehensive scope that explicitly includes the principles of authentication and non-repudiation in addition to the traditional Confidentiality, Integrity, and Availability (CIA) triad.

A. Information Systems Security Engineering (ISSE): This is a process or discipline that applies scientific and engineering principles to develop secure systems; it is the "how-to" of building security in, not the overarching protective concept itself.

B. Information Protection Policy (IPP): This is a specific administrative control—a set of rules and procedures—that governs the protection of information. It is a component of an IA program, not the program itself.

C. Information systems security (InfoSec): This term is more narrowly focused, traditionally on the "CIA triad" (Confidentiality, Integrity, and Availability). IA is a broader term that explicitly adds authentication and non-repudiation to the core principles.

---

1. Committee on National Security Systems (CNSS). (2015). National Information Assurance Glossary

CNSS Instruction No. 4009. Page 35. This official document defines Information Assurance (IA) as: "Measures that protect and defend information and information systems by ensuring their availability

integrity

authentication

confidentiality

and non-repudiation." This definition directly matches the question's wording.

2. National Institute of Standards and Technology (NIST). (2018). Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems. NIST Special Publication 800-160 Volume 1. Page 11

Section 2.2. This publication defines Systems Security Engineering (ISSE is a sub-discipline) as a "specialty engineering discipline... that applies... information assurance principles

" confirming that ISSE is a process that uses IA principles

rather than being the concept itself.

3. Solms

R. V.

& Van Niekerk

J. (2013). From information security to cyber security. Computers & Security

38

97-102. https://doi.org/10.1016/j.cose.2013.04.004. This peer-reviewed article discusses the evolution of terminology

noting that Information Assurance extends the traditional Information Security model to include properties like authenticity and non-repudiation

which are critical for trust in electronic transactions.

4. George Mason University. (n.d.). CYSE 230: Introduction to Network Security Course Syllabus. Volgenau School of Engineering. The course description distinguishes between Information Security (focusing on the CIA triad) and Information Assurance (a broader field including authentication

non-repudiation

and risk management)

which is a common distinction in academic curricula.

The Defense Information Systems Agency (DISA) is a U.S. Department of Defense (DoD) combat support agency. Its core mission is to provide, operate, and assure command and control (C2), information-sharing capabilities, and a globally accessible enterprise information infrastructure. This is accomplished through the Defense Information Systems Network (DISN) and other services that directly support joint warfighters, national-level leaders, and coalition partners. The description in the question is a near-verbatim representation of DISA's official mission statement.

A. DARPA: The Defense Advanced Research Projects Agency is the DoD's research and development arm, focused on creating and preventing strategic surprise by developing breakthrough technologies, not operating current infrastructure.

B. DTIC: The Defense Technical Information Center is the central repository for research and engineering information for the DoD. Its role is information dissemination and archival, not operational command and control.

D. DIAP: The Defense-wide Information Assurance Program was a policy and coordination program, not an operational agency that provides enterprise infrastructure and command and control capabilities.

1. Defense Information Systems Agency (DISA). (n.d.). About DISA. Retrieved from disa.mil. The official mission statement on the DISA website states: "DISA provides

operates

and assures command and control and information-sharing capabilities and a globally accessible enterprise information infrastructure in direct support of joint warfighters

national level leaders

and other mission and coalition partners."

2. U.S. Department of Defense. (2013

July 25). DoD Directive 5105.19: Defense Information Systems Agency (DISA). Section 2

"Mission

" outlines DISA's responsibility to be a "provider of GIG [Global Information Grid] services to the President

the Vice President

the Secretary of Defense

the other National Command Authorities

and the joint warfighter."

3. Ryan

N. J. (2011). Command and Control: The Fifth Element. Joint Force Quarterly

Issue 63

4th Quarter 2011

p. 119. National Defense University Press. This article discusses the evolution of C2 and references DISA's central role in providing the "network and the services" that enable modern net-centric command and control for the joint force.

A Concept of Operations (CONOPS) is a user-oriented document that describes a system's characteristics from an operational perspective. Its primary purpose is to communicate the quantitative and qualitative aspects of a system to all stakeholders (users, buyers, developers, etc.). It details the "who, what, when, where, why, and how" of the system's operation, ensuring a shared understanding of the system's goals, environment, and high-level capabilities before significant engineering effort is expended. This makes it the ideal document for the task described.

A. IMM: An Integrated Master Plan (IMM) is a high-level project management tool focused on significant program events and milestones, not the system's operational characteristics.

C. IPP: An Integrated Program Plan (IPP) is a detailed management plan for program execution, covering aspects like resources and schedules, not the system's functional and operational view.

D. System Security Context: This document is specifically focused on defining the security environment, threats, and objectives, which is only a subset of the overall system characteristics.

1. IEEE Std 1362-1998

IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document. Section 1.1

"Scope

" states the CONOPS document is used to "communicate overall quantitative and qualitative system characteristics to the user

buyer

developer

and other organizational elements."

2. NIST Special Publication 800-160 Vol. 1

Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems. Section 2.3.2.1

"Define Stakeholder Needs and Requirements

" describes the Concept of Operations as a key input that defines the system from the user's viewpoint and clarifies the mission and operational environment for all stakeholders.

3. MIT OpenCourseWare

16.842 Fundamentals of Systems Engineering

Fall 2015. Lecture 5

"Stakeholder Needs Definition

" presents the CONOPS as a foundational document that describes the system in its operational environment

serving as a critical communication tool among all stakeholders.

The "Five Pillars of Information Assurance" is a model, prominently used by the U.S. Department of Defense (DoD) and the Committee on National Security Systems (CNSS), that defines the fundamental goals of securing information and systems. It extends the classic security triad by adding two crucial services. The model is explicitly composed of Confidentiality, Integrity, Availability, Authentication, and Non-repudiation. The question's description is a verbatim definition of this model, which aims to provide a comprehensive framework for protecting and defending information assets.

A. Parkerian Hexad: This model includes six, not five, elements: Confidentiality, Integrity, Availability, Possession/Control, Authenticity, and Utility.

C. Capability Maturity Model (CMM): This is a process improvement and maturity model for organizational development, not a model defining core information security services.

D. Classic information security model: This typically refers to the CIA Triad (Confidentiality, Integrity, Availability) and does not include Authentication or Non-repudiation.

1. Committee on National Security Systems (CNSS). (2010). National Information Assurance (IA) Glossary (CNSSI No. 4009). Page 35. The document defines Information Assurance (IA) as: "Measures that protect and defend information and information systems by ensuring their availability

integrity

authentication

confidentiality

and non-repudiation."

2. Wilson

M.

& Hash

J. (2003). Building an Information Technology Security Awareness and Training Program (NIST Special Publication 800-50). National Institute of Standards and Technology. Page 5

Section 2.1. This publication states

"The five goals of IT security are often referred to as the five pillars of information assurance: confidentiality

integrity

availability

non-repudiation

and authentication."

3. Kam

H-J.

& Cho

S-J. (2015). A Study on the Information Security Education Framework for Developing Countries. Journal of Security Engineering

12(6)

607-618. Page 609 discusses the "Five Pillars of Information Security" as Confidentiality

Integrity

Availability

Authentication

and Non-repudiation

citing them as the core components of information assurance education. DOI: https://doi.org/10.14257/jse.2015.12.06

4. Naval Postgraduate School. (2004). CS3670: Secure Computer Systems Course Syllabus. Department of Computer Science. The course objectives explicitly mention understanding the "five pillars of Information Assurance (confidentiality

integrity

availability

non-repudiation

and authentication)." This demonstrates its use in academic curricula for information systems security engineering.

MIL-STD-499B is a prescriptive standard that defines the required activities and processes for a systems engineering (SE) effort. The direct benefits of applying this standard are the establishment of crucial management and control structures mandated within its text. These include developing work breakdown structures (WBS) and statements of work (SOW) for clear project definition, establishing and maintaining rigorous configuration management for system integrity, and developing user training materials as part of integrated logistics support. These tangible outputs and processes are the direct, "stated" results of the standard's application, as opposed to a high-level summary of the discipline's goals.

D. This describes the ultimate, high-level goal of the SE discipline, but it is not a specific process or benefit explicitly stated within the prescriptive text of the MIL-STD-499B document.

1. MIL-STD-499B (Draft)

Systems Engineering

1 May 1992.

For A & B: Section 4.2.3

"Systems analysis and control

" explicitly requires the implementation of "Configuration management" and the use of a "Work Breakdown Structure (WBS)" as part of the SE control function.

For C: Section 4.2.1

"Process integration

" requires the integration of "integrated logistics support" (ILS) into the main engineering effort. A key element of ILS is ensuring the system is supportable

which includes the development of user training procedures and data.

2. Defense Acquisition University (DAU). Systems Engineering Fundamentals. December 2001.

For A

B

C: Chapter 4

"The Systems Engineering Process

" details the core activities derived from standards like MIL-STD-499. It describes the WBS as a key tool for planning

Configuration Management as essential for control

and logistics support (including training) as a critical integrated element. This confirms A

B

and C are core

stated processes.

For D: The guide's introduction states the goal of SE is to "help Programs develop and field affordable and effective systems

" confirming that D is a high-level goal

not a specific

stated process-level benefit from the standard itself.

3. NASA/SP-2016-6105 Rev 2

NASA Systems Engineering Handbook.

Appendix C

"Historical Information

" references MIL-STD-499 as a foundational document. The handbook consistently distinguishes between the SE processes (like configuration management and technical planning) and the overall purpose of SE

which is to meet stakeholder needs regarding performance

cost

and schedule (aligning with option D as a goal

not a stated process).

A packet-filtering firewall operates at the Network layer (Layer 3) of the OSI model. It examines the header of each packet passing through it and makes a filtering decision based on a set of rules. These rules typically use information found in the IP header (source and destination addresses) and the TCP/UDP header (source and destination ports), which corresponds to the Transport layer (Layer 4). This type of firewall is stateless, meaning it treats each packet as an isolated event without considering the context of previous packets.

A. Circuit-level gateway: This firewall operates at the Session layer (Layer 5). It validates TCP handshakes but does not inspect the actual packet contents or headers beyond establishing the session.

B. Application gateway: This firewall, also known as a proxy firewall, operates at the Application layer (Layer 7). It understands application-specific protocols and can filter traffic based on content.

C. Proxy server: This is a general term for an intermediary server, and in the context of firewalls, it typically refers to an application-level gateway that operates at the Application layer (Layer 7).

1. National Institute of Standards and Technology (NIST). (2009). Guidelines on Firewalls and Firewall Policy (Special Publication 800-41 Revision 1).

Section 2.1.1

"Packet Filter Firewalls

" Page 2-2: "Packet filter firewalls work at the network layer of the Open Systems Interconnection (OSI) model... Packet filters can filter traffic based on the packet header information: source and destination IP addresses

source and destination ports

and the protocol type (e.g.

TCP

UDP

ICMP)."

2. Stallings

W.

& Brown

L. (2018). Computer Security: Principles and Practice (4th ed.). Pearson.

Chapter 20.2

"Firewall Characteristics and Access Policy

" Section "Types of Firewalls": Describes packet filtering firewalls as applying a set of rules to each incoming and outgoing IP packet

making decisions based on fields in the IP and transport (TCP or UDP) headers

including source/destination IP addresses and port numbers.

3. Al-Shaer

E.

& Hamed

H. (2004). A Survey on Firewall Technologies. IEEE Communications Surveys & Tutorials

6(1)

24-41.

Section II.A

"Packet Filtering Firewalls

" Page 26: "Packet filtering firewalls operate at the network layer of the OSI model... The filtering decision is based on the information contained in the packet header

such as source and destination IP addresses

source and destination ports..." (DOI: https://doi.org/10.1109/COMST.2004.5342224)