Operational Event-Trace Description
February 27, 2008
OV-6c Template
Product Definition. The Operational Event- Trace Description provides a time-ordered examination of the information exchanges between participating operational nodes as a result of a particular scenario. Each event-trace diagram should have an accompanying description that defines the particular scenario or situation.
Product Purpose. OV-6c is valuable for moving to the next level of detail from the initial operational concepts. The product helps define node interactions and operational threads. The OV-6c can also help ensure that each participating operational node has the necessary information it needs at the right time in order to perform its assigned operational activity.
Product Detailed Description. OV-6c allows the tracing of actions in a scenario or critical sequence of events. OV-6c can be used by itself or in conjunction with OV-6b to describe the dynamic behavior of business processes or a mission/operational thread. An operational thread is defined as a set of operational activities, with sequence and timing attributes of the activities, and includes the information needed to accomplish the activities. A particular operational thread may be used to depict a capability. In this manner, a capability is defined in terms of the attributes required to accomplish a given mission objective by modeling the set of activities and their attributes. The sequence of activities forms the basis for defining and understanding the many factors that impact on the capability.
Integrated architectures with DOTMLPF information provide a structured and organized approach for defining capabilities and understanding the underlying requirements for achieving those capabilities. By describing the sequence and timing of activities, tying them to the operational nodes (representing organizations or human roles), relating them to their supporting systems or system functions, and specifying the actions, events, and related guard conditions or business rules that constrain those activities, the full spectrum of DOTMLPF is modeled and related, so that analyses and decisions can be supported. Below is a detailed description of how DOTMLPF is tightly woven into this and related products.
Doctrine is represented as guard conditions, which are associated with events, which, in turn, map to controls in OV-5.
Organization is represented via the lifelines or swimlanes, which map to operational nodes of OV-2; which, in turn, map to organizations, organization types, or human roles of OV-4; and mechanisms in OV-5.
Training is represented via the lifeline or swimlane, since the operational node (shown on the dia gram as a lifeline or swimlane) may represent a human role, which, in turn, embodies a certain skill set or knowledge domain required to perform the actions (which are, in turn, related to operational activities of OV-5).
Materiel is tied to the elements in OV-6c because this product is tightly coupled with OV-5, where mechanisms may be used to represent systems that support operational activities. In addition, further materiel detail may be related to the activities via SV-5, by relating those activities to the system functions that are executed by systems that automate them (wholly or partially). Each operational thread or scenario (represented by an OV-6c) is associated with a certain capability, since a capability is defined in terms of the activities and their attributes depicted in OV-6c. Consequently, an SV-5 may also be used to relate a capability to the systems that support it, by labeling a set of activities with their associated capability (defined in OV-6c), and by labeling the system functions with the systems that execute them (defined in SV-1, SV-2, and SV-4).
Leadership may be represented either directly via the lifeline or swimlane or indirectly through the relationships of an operational node (shown as a lifeline or swimlane on the diagram) in OV-2 to organizations, organization types, or leadership human roles in OV-4.
Personnel may be represented directly via the lifeline or swimlane, or indirectly through the relationships of an operational node (shown as a lifeline or swimlane on the diagram) in OV-2 to organizations, organization types, or human roles in OV-4.
Facility is tied to the elements in OV-6c because the lifeline or swimlane representing an operational node is directly tied to the systems node (facilities) that house the systems, which may be shown as mechanisms that support operational activities.
Popularity: 2% [?]
Operational Activity Model (OV-5)
February 27, 2008
OV-5 Template
Product Definition. The Operational Activity Model describes the operations that are normally conducted in the course of achieving a mission or a business goal. It describes capabilities, operational activities (or tasks), input and output (I/O) flows between activities, and I/O flows to/from activities that are outside the scope of the architecture. High- level operational activities should trace to (are decompositions of) a Business Area, an Internal Line of Business, and/or a Business Sub-Function as published in OMB’s Business Reference Model [OMB, 2003].
Product Purpose. OV-5 can be used to:
Clearly delineate lines of responsibility for activities when coupled with OV-2
Uncover unnecessary operational activity redundancy
Make decisions about streamlining, combining, or omitting activities
Define or flag issues, opportunities, or operational activities and their interactions (information flows among the activities) that need to be scrutinized further
Provide a necessary foundation for depicting activity sequencing and timing in OV-6a, OV-6b, and OV-6c
Product Detailed Description. OV-5 describes capabilities, operational activities (or tasks), I/O flows between activities, and I/O flows to/from activities that are outside the scope of the architecture.
The Framework does not endorse a specific modeling methodology. However, if the Integration Definition for Function Modeling (IDEF0) method [FIPS 183, 1993] is used, the activities also show controls (factors that affect the way that the activity is performed) and may show mechanisms (the resources, including operational nodes, that perform the activity). While some may illustrate corresponding systems as mechanisms in this model, the reader is cautioned that the introduction of system data early in the development of the OV may result in limiting system design and implementation decisions.
I/Os of operational activities relate to information elements of OV-3 and are further characterized by the information exchange attributes described in OV-3. I/Os that are produced or consumed by leaf operational activities that cross operational node boundaries are carried by needlines of OV-2. In addition, operational activities can be annotated (e.g., via the mechanism arrow in an IDEF0 diagram) with the corresponding operational node from OV-2. Annotations to the activities may also identify the costs (actual or estimated) associated with performing each activity. The business rules that govern the performance of the activities can also be keyed to each activity. (Business rules are described in OV-6a.) Annotations to OV-5s can further the purposes of the description by adding specific attributes of exchanged information, which can later be used in OV-3.
OV-5 is a key product for describing capabilities and relating capabilities to mission accomplishment. The DoD Dictionary of Military Terms [DoD JP 1-02, 2001] defines a capability as “the ability to execute a specified course of action. (A capability may or may not be accompanied by an intention.)” A capability can be defined by one or more sequences of activities, referred to as operational threads or scenarios. A capability may be further described in terms of the attributes required to accomplish the set of activities (such as the sequence and timing of operational activities or materiel that enable the capability), in order to achieve a given mission objective. Capability-related attributes may be associated with specific activities or with the information flow between activities, or both. When represented by a set of operational activities, a capability can also be linked to an operational node in an OV-2.
Integrated architectures with Doctrine, Organization, Training, Materiel, Leadership & education, Personnel, and Facilities (DOTMLPF) information provide a structured and organized approach for defining capabilities and understanding the underlying requirements for achieving those capabilities. The full spectrum of DOTMLPF is modeled and related so that analyses and decisions can be supported by describing the sequence and timing of activities; tying them to the operational nodes (representing organizations or human roles); relating them to their supporting systems or system functions; and specifying the actions, events, and related guard conditions or business rules that constrain those activities. Below is a detailed description of how DOTMLPF is tightly weaved into this and related products.
Doctrine is represented as controls (or guard conditions) in OV-5.
Organization is represented via the operational nodes of OV-2, which can be shown as mechanisms (or annotations to the activities) in OV-5.
Training is represented via the operational node, which may represent a human role which in turn, embodies a certain skill set or knowledge domain required to perform the activities, which are, in turn, related to operational activities of OV-5.
Materiel is tied to the elements in OV-5, where mechanisms may be used to represent systems that support operational activities. In addition, further materiel detail may be related to the activities via SV-5, by relating those activities to the system functions that are executed by systems that automate them (wholly or partially). Each operational thread or scenario (represented by an OV-6c) is associated with a certain capability, since a capability is defined in terms of the activities and their attributes depicted in OV-6c. Consequently, an SV-5 may also be used to relate a capability to the systems that support it, by labeling a set of activities with its associated capability (defined in OV-6c), and by labeling the system functions with the systems that execute them (defined in SV-1, SV-2, and SV-4).
Leadership may be represented indirectly in OV-5 by first mapping activities to operational nodes via mechanisms and through the relationships of an operational node in OV-2 to organizations, organization types, or leadership human roles in OV-4.
Personnel may be represented indirectly through the relationships of an operational node in OV-2 to organizations, organization types, or human roles in OV-4.
Facility is tied to OV-5, because an operational node is directly tied to the systems nodes (facilities) that house the systems, which may be shown as mechanisms that support operational activities.
OV-5 graphic(s) may include a hierarchy chart of the activities covered in the model. A hierarchy chart helps provide an overall picture of the activities involved and a quick reference for navigating the OV-5 I/O flow model.
OV-5 is frequently used in conjunction with a process flow model (such as an IDEF3 model, or a UML sequence diagram) that describes the sequence and other attributes (e.g., timing) of the activities. A process flow model further captures precedence and causality relations between situations and events by providing a structured method for expressing knowledge about how a process or organization works. In addition, a process flow model may be annotated with the names of the operational nodes responsible for conducting those activities. A process flow model may be described in OV-6c.
The decomposition levels and the amount of detail shown on OV-5 should be aligned with the operational nodes that are responsible for conducting the operational activities (shown on corresponding OV-2 products). It is important to note that OV-5 is intended to be only as exhaustive as necessary to attain the objectives for the architecture as stated in AV-1.
Popularity: 3% [?]
Organizational Relationships Chart (OV-4)
February 25, 2008
Product Definition. The Organizational Relationships Chart illustrates the command structure or relationships (as opposed to relationships with respect to a business process flow) among human roles, organizations, or organization types that are the key pla yers in an architecture.
Product Purpose. This product clarifies the various relationships that can exist between organizations and sub-organizations within the architecture and between internal and external organizations.
Product Detailed Description. OV-4 illustrates the relationships among organizations or resources in an architecture. These relationships can include supervisory reporting, command and control relationships, and command-subordinate relationships. Another type of relationship is a coordination relationship between equals, where two organizations coordinate or collaborate without one having a supervisory or command relationship over the other. Others may be defined depending on the purpose of the architecture. Architects should feel free to define any kinds of relationships necessary and important within their architecture to support the goals of the architecture. For example, dynamic teams or task forces (i.e., new operational nodes) may be created in real time with only limited lifespans and assigned missions, and could have needlines assigned to them. The creating node and the created node have a unique relationship that should be documented. This relationship may not be one of lines of command or organizational hierarchies, as these do not necessarily map to the needlines of OV-2. In this product, the dynamic organizations represented by operational nodes in OV-2 have a limited lifespan and a temporary collaboration relationship.
The product illustrates the relationships among organizations or organization types that are the key players in an architecture. These key players correspond to the operational nodes of an OV-2, which contains added detail on how the key players interact together in order to conduct their corresponding operational activities of OV-5.
Human roles whose skills are needed to perform the operational activities or business processes described in the architecture may also be defined in OV-4. The corresponding operational activities should be decomposed to a degree that allows them to be correlated to specific human roles within organizations. In addition, and specifically in the case of target architectures, human roles that do not reflect a specific supervisory reporting, command and control, or coordination organizational structure may be used in OV-4. In this case, OV-4 may be developed using strictly human roles that are the key players in an architecture.
Organizational relationships are important to depict in an OV (for a current architecture), because they can illustrate fundamental human roles (e.g., who or what type of skill is needed to conduct operational activities) as well as management relationships (e.g., command structure or relationship to other key players). Also, organizational relationships may influence how the operational nodes in an OV-2 are connected.
Popularity: 2% [?]
Operational Node Connectivity Description (OV-2)
February 25, 2008
OV-2 Example
Product Definition. The Operational Node Connectivity Description graphically depicts the operational nodes (or organizations) with needlines between those nodes that indicate a need to exchange information. The graphic includes internal operational nodes (internal to the architecture) as well as external nodes.
Product Purpose. OV-2 is intended to track the need to exchange information from specific operational nodes (that play a key role in the architecture) to others. OV-2 does not depict the connectivity between the nodes.
Product Detailed Description. The main features of this product are the operational nodes and the needlines between them that indicate a need to exchange information. The product indicates the key players and the interactions necessary to conduct the corresponding operational activities of OV-5.
Operational Nodes. An operational node is an element of the operational architecture that produces, consumes, or processes information. What constitutes an operational node can vary among architectures, including, but not limited to, representing an operational/human role (e.g., Air Operations Commander), an organization (e.g., Office of the Secretary of Defense) or organization type, i.e., a logical or functional grouping (e.g., Logistics Node, Intelligence Node), and so on. The notion of operational node will also vary depending on the level of detail addressed by the architecture effort.
Needlines and Information Exchanges. A needline documents the requirement to exchange information between nodes. The needline does not indicate how the information transfer is implemented. For example, if information is produced at node A, is simply routed through node B, and is used at node C, then node B would not be shown on the OV-2 diagram - the needline would go from node A to node C. OV-2 is not a communications link or communications network diagram. The system implementation (or what systems nodes or systems are used to execute the transfer) is shown in the Systems Interface Description (SV-1). Furthermore, the needline systems equivalent is the interface line depicted in SV-1. The actual implementation of an interface may take more than one form and is documented in a Systems Communications Description (SV-2). Therefore, a single needline shown in the OV may translate into multiple interfaces in SV-1 and multiple physical links in SV-2.
Needlines are represented by arrows (indicating the direction of information flow) and are annotated with a diagram- unique identifier and a phrase that is descriptive of the principal types of information exchanged. It is important to note that the arrows on the diagram represent needlines only. This means that each arrow indicates only that there is a need for some kind of information transfer between the two connected nodes.
There is a one-to- many relationship from needlines to information exchanges (e.g., a single needline on OV-2 represents multiple individual information exchanges). The mapping of the information exchanges to the needlines of OV-2 occurs in the Operational Information Exchange Matrix (OV-3). For example, OV-2 may list Situational Awareness as a descriptive name for a needline between two operational nodes. In this example, the needline represents a number of information exchanges, consisting of various types of reports (information elements), and their attributes (such as periodicity and timeliness) that are associated with the Situational Awareness needline. The identity of the individual information elements and their attributes are documented in OV-3.
OV-2 should also illustrate needs to exchange information between operational nodes and external nodes (i.e., operational nodes that are not strictly within the scope of the subject architecture but that act as important sources of information required by nodes within the architecture or important destinations for information provided by nodes within the architecture). Operational Activities. The operational activities (from the OV-5 Operational Activity Model) performed by a given node may be listed on the graphic, if space permits. OV-2, in effect, turns OV-5 inside out, focusing first-order on the operational nodes and second-order on the activities. OV-5, on the other hand, places first-order attention on operational activities and only second-order attention on nodes, which can be shown as annotations on the activities.
Representation of the product. For complex architectures, OV-2 may consist of multiple graphics. There are at least two different ways to decompose OV-2. One method involves using multiple levels of abstraction and decomposing the nodes. Another method involves restricting the nodes and needlines on any given graphic to those associated with a subset of operational activities. Both of these methods are valid and can be used together.
OVs usually avoid representing real physical facilities as operational nodes and focus on virtual or logical nodes that can be based on operational (human) roles or missions. Operational nodes are independent of materiel considerations; indeed, they exist to fulfill the missions of the enterprise and to perform its tasks and activities (business processes, procedures, and operational functions). Use of operational nodes supports analysis and design by separating business process modeling and information requirements from the materiel solutions that support them. Similarly, tasks and activities are organized, and communities of interest are defined to suit the mission and process requirements; the materiel is flexibly and automatically configurable to support the operational processes. However, an OV often has materiel constraints and requirements that must be addressed. Where appropriate, system or physical nodes that constitute the location of an operational node may augment the description of an operational node. These are often taken as recommendations or boundaries for further SV details.
Popularity: 3% [?]
DIACAP Activity #4 Maintain Authorization to Operate and Conduct Review
February 21, 2008
Maintain Situational AwarenessIncluded in the IA controls assigned to all DoD ISs are IA controls related to configuration and vulnerability management, performance monitoring, and periodic independent evaluations (e.g., penetration testing). The IAM continuously monitors the system or information environment for security-relevant events and configuration changes that negatively impact IA posture and periodically assesses the quality of IA controls implementation against performance indicators such as security incidents, feedback from external inspection agencies (e.g., IG DoD, Government Accountability Office (GAO)), exercises, and operational evaluations. In addition the IAM may, independently or at the direction of the CA or DAA, schedule a revalidation of any or all IA controls at any time. Reference (a) requires revalidation of a select number of IA controls at least annually. (DoD 8510.01, 6.3.4.1)
Knowing what is going on with the system is the job of the Information Assurance Manager (IAM). This can be delegated to the Information Assurance Officer (IAO) or the IAM and IAO may be the same person, but keep in mind that these permission require training, a technical and security certification (IAW DoD 8570).
Maintain IA Posture
Ensuring that there are no changes to the IA posture falls on the shoulders of the IAM. This includes making sure that the establish baseline of the system has no signifigant changes. Most patches (even involving security) will have a minimal impact on the system. Applicable patches should always be tested before being put on a system. Major patches are usually service packs that may actually change the IA posture. The DIACAP Team should be involved with any major changes to the IA posture. They will also decide which modifications, upgrades and additions should be considered changes to the IA posture of the system. As a minimum, the Program Manager, IAM, subject matter experts (software/system security engineers) and information system owner/user representative should be appart of that decision.
What will likely be considered a change to the IA Posture:
Adding IA products (firewalls, intrusion detection systems, ect)
Some internetworking devices such as Routers and Switches
New operating systems
Major upgrades to software or operating systems (not including support applications)
Newly discover major vulnerabilities
*Basically any major changes that will affect the security, supportability, usability, and interoperability of the system. It is important to have who, what when and where of sustainability, new risks, and usability requirements in writing. Information Assurance includes all these things, not just security.
What are usually not changes to the IA Posture:
Most NOTAM/IAVAS/TCNOs (such as Office patches, browser upgrades, ect)
Re-positioning equipment within the office (as long as the IAM has readable documentation on the data connections)
Adding passive periferal devices such as stand-alone printers, scanners and new monitors (devices with connectivity to external sources such as faxes, share external network printers should go before the DIACAP Team)
Devices such as DVD, CD and hard drives with more capacity may not affect the IA Posture but it is best to have some formalized method of tracking upgrades to hardware especially on mission systems as some changes could have some unpredictable affects
Annual FISMA Reviews
DIACAP includes the task of performing reviews annually on the system. This is one of the key features of the Federal Information System Management Act of 2002. What ever command or branch of the DoD you reside, your system has the potential of being audited annually to make sure it is in compliance with federal regulations. The eMASS IT Portfolio management systems (EITDR, DITPR-DON, APMS) also has this feature intergrated into its key functions. All data on each systems IA posture is collect annually. This is done by the IAMs and/or the DIACAP Team.
Additionally, each system must be re-accredited every three years:
6.3.4.4. Initiate Reaccreditation. In accordance with OMB Circular A-130 (Reference (s)), an IS must be recertified and reaccredited once every 3 years. The results of an annual review or a major change in the IA posture at any time may also indicate the need for recertification and reaccreditation of the IS. DoD 8510.01, 6.3.4.4
From DoD 8510.01, DIACAP:
6.3.4.1.1. DoD ISs with a current ATO that are found to be operating in an unacceptable IA posture through GAO audits, IG DoD audits, or other reviews or events such as an annual security review or compliance validation shall have the newly identified weakness added to an existing or newly created IT Security POA&M.
6.3.4.1.2. If a newly discovered CAT I weakness on a DoD IS operating with an ATO cannot be corrected within 30 days, the system can only continue operation under the terms prescribed in subparagraph 6.3.3.2.6.1.2.
6.3.4.1.3. If a newly discovered CAT II weakness on a DoD IS operating with a current ATO cannot be corrected or satisfactorily mitigated within 90 days, the system can only continue operation under the terms prescribed in subparagraph 6.3.3.2.6.2.5.
6.3.4.2. Maintain IA Posture. The IAM may recommend changes or improvement to the implementation of assigned IA controls, the assignment of additional IA controls, or changes or improvements to the design of the IS itself.
6.3.4.3. Perform Reviews. The IAM shall annually provide a written or DoD PKI-certified digitally signed statement to the DAA and the CA that indicates the results of the security review of all IA controls and the testing of selected IA controls as required by Reference (a). The review will either confirm the effectiveness of assigned IA controls and their implementation, or it will recommend: changes such as those described in subparagraph 6.3.4.2.; a change in accreditation status (e.g., accreditation status is downgraded to IATO or DATO); or development of an IT Security POA&M. The CA and DAA shall review the IAM statement in light of mission and information environment indicators and determine a course of action that will be provided to the concerned CIO or SIAO for reporting requirements described in Reference (a). The date of the annual security review will be recorded in the SIP. A DAA may downgrade or revoke an accreditation decision at any time if risk conditions or concerns so warrant.
6.3.4.4. Initiate Reaccreditation. In accordance with OMB Circular A-130 (Reference (s)), an IS must be recertified and reaccredited once every 3 years. The results of an annual review or a major change in the IA posture at any time may also indicate the need for recertification and reaccreditation of the IS.
Popularity: 7% [?]
Register the System with DoD IA Component
February 9, 2008
Register the System with DoD IA Component
Each branch of the military has an IA component. Each of the US Armed Services have a division under their respective chief information officer’s responsible for all computers, communications and networks in a given military branch. These communications divisions will house the Information Assurance component responsible for the DIACAP tasks.
Table 1. DoD IA Components
| DoD Branch |
Branch Communication & Information Service |
|
| US Air Force |
Air Force Communication Agency (AFCA) |
AFCA/EV |
| US Army |
*Army NETCOM 9th Signal Corps |
Army NETCOM Information Assurance Office |
| Department of the Navy |
DON CIO |
DON SIAO |
*more on Army NETCOM
Its important to get registered as soon as possible, because the DIACAP process (as with any certification & accreditation process) can take well over from six months to accomplish.
Role of the IA Component
Within the DIACAP Team, the IA Component’s role will likely be the “Certifying Authority” which is responsible for the final validation of security controls. This role is powerful in that it will determine whether or not the system is certified. The designated accreditation authority (DAA) listens the the recommendation of the CA. If the CA validates, the DAA will accredit. Also, the DAA can actually be within the IA Component, depending on the Mission Assurance Category (MAC) level (ref: USAF IT Lean/SISSU guidelines, this may differ within Army & DON).
IA Component’s IT Portfolio
DoD IT portfolio management (DoDD 8115.01) requires that each of the branches report to the DoD the status of IT systems. Each branches IA Component has a Enterprise Mission Assurance Support Service (eMASS). You will likely be tasked with entering your system into that database. This is what is essentially meant by register the system with the DoD IA Component.
More on DoD IT portfolio management & eMASS
Popularity: 6% [?]
Security, Interoperability, Supportability, Sustainability and Usability (SISSU)
February 5, 2008
The Security, Interoperability, Supportability, Sustainability and Usability (SISSU) is considered a part of the USAF IT LEAN process. SISSU is a comprehensive database of security controls (IA Controls) addressed in DoDI 8500.02 needed to complete the DIACAP process.
The SISSU questions includes everything from documentation of the system to physical security, to network security. To access the SISSU process in the EITDR one need an account and “stakeholders list” approval via AFCA/EV.
Security, Interoperability, Supportability, Sustainability and Usability are each considered disciplines. Each discipline is assigned a set of roles: producer, reviewer, validator, and approver. Once all of these roles have done their part on each of their applicable questions in a given discipline they can move on to the next phase. The phases are Define Need, Design, Build & Test, and Release.
Popularity: 6% [?]
USAF Enterprise Information Technology Data Repository (EITDR)
February 3, 2008
The EITDR is a database controlled and managed by AFCA/EV. It includes information on most UNCLASS USAF IT systems. All data is uploaded from the EITDR into the Department of Defense Information Technology Profile Registry (DITPR) to meet Federal Information System Management Act requirements.
The DIACAP process is only a small part of what the data collected in the EITDR. The system is used to keep track of new acquisitions, new major DoD mandate compliance, program management and system engineering documentation.
EITDR maintains the Security, Interoperability, Supportability, Sustainability and Usability (SISSU) of all applicable systems. This process lists all DIACAP IA Controls. Stakeholder’s in the DIACAP Process (DIACAP Team) must be selected in order to access the SISSU process.
In the EITDR SISSU Phases are broken into Define Need, Design, Build and Test and Sustain And Release. The questions are put into the following disciplines: Security, Interoperability, Supportability/Sustainability and Usability. The IA Component (AFCA/EVSS) is responsible for validating & approving the Security phase. All the other disciplines Validators and Approvers are chosen by the agency registering the system.
Popularity: 7% [?]
Approved IA Products
February 3, 2008
This does not apply to types of devices and/or applications only IA Products (firewalls, IDS, anti-virus ect) and IA-Enabled products (operating systems, Routers, DBMS ect). If the IA Enabled product lets say a router will be used as a dumb device like a hub in which it is just passing data between two stand alone computers (no connection to the Internet or major LAN) you probably don’t need to worry about most of this. All systems that are IA-Enabled or IA Products (defined below) that require the use of IA capabilities must match IA “protection profiles” for a particular technology. In other words, if you have a firewall (which is an IA Product) it has to have all of the security, cryptological and robust features detailed in the applicable NIAP firewall list of features better known as protection profiles. I wish it were that simple. But the firewall in the example above also has to comply with the evaluation and validation requirements of NSTISSP No. 11 which states that the firewall you bought must have a Common Criteria evaluation. Furthermore, each branch of the DoD has a list of products that they prefer that you purchase due to contractual arrangements. In the end your best bet is to only buy IA-Enabled and IA Products that have an IA capability (will protect data in some way) that are on this site http://www.niap-ccevs.org or have been accredited in accordance with the Common Criteria. If the device is not on the NIAP site you may able to find something close by googling “[YOUR PRODUCT Common Criteria]”. Also, keep in mind that all operating systems may have to have anti-virus applications that must also meettheir protection profiles.
Protection Profiles: http://www.niap-ccevs.org/cc-scheme/pp/index.cfm
Products used within the Department of Defense may be submitted for evaluation at evaluation assurance levels (EALs) 1-7 through the NIAP Common Criteria Evaluation and Validation Scheme (CCEVS). Alternatively, the United States recognizes products that have been evaluated under the sponsorship of other signatories and in accordance with the International Common Criteria E2.1.30.
IA-Enabled Product. Product or technology whose primary role is not security, but which provides security services as an associated feature of its intended operating capabilities. Examples include such products as security-enabled web browsers, screening routers, trusted operating systems, and security-enabled messaging systems. E2.1.29.
IA Product. Product or technology whose primary purpose is to provide security services (e.g., confidentiality, authentication, integrity, access control or non-repudiation of data); correct known vulnerabilities; and/or provide layered defense against various categories of non-authorized or malicious penetrations of information systems or networks. Examples include such products as data/network encryptors, firewalls, and intrusion detection devices. (DoDI 8500.2) http://www.niap-ccevs.org/cc-scheme/
Product Specification and Evaluation
(DoDI 8500.2) E3.2.5. Product Specification and Evaluation. At the enterprise level, implementation-independent specifications for IA and IA-enabled IT products are provided in the form of protection profiles. Protection profiles are developed in accordance with the Common Criteria (reference (j)) within the NIAP framework. Regardless of the mission assurance category or confidentiality level of the DoD information system, all incorporated IA products, and IA-enabled IT products that require use of the product’s IA capabilities, acquired under contracts executed after July 1, 2002, shall comply with the evaluation and validation requirements of NSTISSP No. 11 (reference (ah)), with the following qualifications: E3.2.5.1. If an approved U.S. Government protection profile exists for a particular technology area and there are validated products available for use that match the protection profile description, then acquisition is restricted to those products; or to products that vendors, prior to purchase, submit for evaluation and validation to a security target written against the approved protection profile. Products used within the Department of Defense may be submitted for evaluation at evaluation assurance levels (EALs) 1-7 through the NIAP Common Criteria Evaluation and Validation Scheme (CCEVS). Alternatively, the United States recognizes products that have been evaluated under the sponsorship of other signatories and in accordance with the International Common Criteria for Information Security Technology Evaluation Recognition Arrangement (CCRA) for EALs 1-4 only. E3.2.5.2. If an approved U.S. Government protection profile exists for a particular technology area, but no validated products that conform to the protection profile are available for use, the acquiring organization must require, prior to purchase, that vendors submit their products for evaluation and validation by a NIAP EVP or CCRA laboratory to a security target written against the approved protection profile or acquire other U.S.-recognized products that have been evaluated under the sponsorship of other signatories to the CCRA. E3.2.5.3. If no U.S. Government protection profile exists for a particular technology area and the acquiring organization chooses not to acquire products that have been evaluated by the NIAP CCEVS or CCRA laboratories, then the acquiring organization must require, prior to purchase, that vendors provide a security target that describes the security attributes of their products, and that vendors submit their products for evaluation and validation at a DAA-approved EAL. Robustness requirements, mission, and customer needs will together enable an experienced information systems security engineer to recommend a specific EAL for a particular product to the DAA.
Popularity: 4% [?]
DIACAP Activity #2 Implement and Validate Assigned IA Controls
February 2, 2008
This activity is marked by actually putting the IA Controls into action. This means not only coordinating with software and/or system developers and engineers, but testing the IA Controls once they have been implemented.
Execute the DIACAP Implementation Plan
Executing the DIACAP Implementation Plan is the most critical part of the DIACAP process because it focuses almost exclusively on the assigned security controls. Your system may very well get an authorization to operate but if it does not have the appropriate security controls it could be a detriment to an organization and anything its is attached to by being an enormous vulnerability that is easily hacked or, more likely, a wasteful product that is very difficult to support in the long term. If anything, it is more important to get the IA Controls implemented than it is to get the system approved although the process is such that you should not have one without the other.
IA Controls are not just about security but include what the Air Force has called SISSU which stands for security, interoperability, sustainability, supportability and usability. All these features are checked annually under the DIACAP (activity #4).
The time it takes to implement the system should factor in any additional time it might take to implement and test the IA Controls.
Resistance to the Implementation of IA Controls
Be prepared for panic and gnashing of teeth when you tell them what is needed. Implementing the security controls can be a challenge. The cost, time and energy it takes to accomplish all the IA Controls can be intimidating at first glance.
Some engineers, program managers and system owners will resist the implementation of IA Controls, particularly if it is a legacy system that has operated just fine for years without any security controls. When dealing with reluctant customers the best thing you can do is come to meetings armed with federal regulations, operating instructions and mandates that have been issued by the DoD and signed by generals. You should be familiar enough to fully inform the customer of the risks associated with being non-compliant. Make sure that they are informed about how visible the system is in the eMASS database. Many times system owners will completely ignore regulations until they are absolutely forced to comply and by then they don’t have funding or time to comply.
Methods of Implementing the IA Controls
The technicians and/or engineers who are actually developing the system and installing the IA Controls should know about the tools that will make their job much easier.
For Windows systems those implementing the IA Controls should know about the following:
- Security Technical Implementation Guide (STIG)
- Security Guides
- Gold Disk
- Federal Standard Configuration Operating Systems (if applicable)
For Unix/Linux Systems:
- Security Technical Implementation Guide (STIG)
- Security Guides
- Security Readiness Review (SRR)
Implementing Windows IA Controls
The quickest way to implement IA Controls on Windows systems is to use automated methods first to find and implement as many technical security features as possible and use STIGS and security guides for the remaining security controls that should be implemented. On a mission system, it is important to know that some security controls may break some critical functions. Some security controls can be ignored, some can be mitigated, some can have waivers and others absolutely must be complied with in some way, shape or form.
Federal Standard Configuration Operating Systems (if applicable)
Windows based systems with connections to the Global Information Grid may need to use a Federal Standard Configuration OS. This disk has various names. The USAF calls this disk the Standard Desktop Configuration (SDC) and Standard Server Configuration (SSC) for servers. Some federal organizations have Federal Desktop Common Configuration (FDCC), the Navy has NMCI systems and Army has Gold Master systems. These are locked down versions of Windows XP or Vista systems (depending on the version) that are only supposed to be altered under specialized circumstances.
These standard configurations may pose as a serious technical issue for mission systems that are not standard. Sustainment/Supportability funding might also be an issue for mission systems as SDC is mostly designed for systems with basic computing needs in a base area networks that uses devices like Microsoft System Management Service (SMS) to conduct automated pushes from all systems on the network. Mission systems usually have to be tested separately in order make sure new upgrades and IAVA’s don’t negatively affect the mission. Your system may be able to attain a waiver for the standard configuration. This configuration may not be needed for Windows systems not connected to the GIG.
DISA has disk called the Gold Disk that can scan for Category 1, 2 and 3 vulnerabilities according the applicable Mission Assurance Level. It can also automatically fix these vulnerabilities for Windows NT/XP and Vista. This scan should also be run on the standard configuration systems. You’ll be surprise how many vulnerabilities will show up even on standard configurations such as USAF SDC.
The challenges with the Gold Disk include the following: 1) there may be false positives. For example, Gold Disk may tell you that the Guest account should be removed. But Guest account is a built-in feature in Windows so it can only be disabled. 2) Some Category 1’s and 2’s may not be fixable on mission systems (especially legacy systems). In which case, it may have to be marked as non-compliant in the appropriate IA Controls. 3) Not all vulnerability Categories match up with the IA Controls so some of it will be up to your discretion. Also, the Cat 1, 2, or 3 results might not be applicable to your system. For example, you may have Internet Explorer vulnerabilities that pop-up on a system that will not actually use port 80 or the web at all.
Gold Disk is automated but it still needs a fairly technical & security oriented person to interpret the data.
Implementing UNIX/LINUX IA Controls
Unlike Windows there is no standard configuration for any UNIX environment. Currently, there are no plans published to change this. UNIX does have an automated script called the Security Readiness Review (SRR). Running the script requires solid skills in the command line. SRR picks up a lot of false positives so the technician/engineer running the script really needs to know what is running on the system and what does not need to be running. UNIX knowledge is really a must to use the SRR effectively.
The UNIX SRR Scripts are supported on the following platforms and versions:
Solaris 2.5.1 through Solaris 10; HP-UX 11.0, HP-UX 11.11; Red Hat Enterprise Linux 3 and 4; and AIX 4.3. - http://iase.disa.mil/stigs/SRR/index.html
IA Control ECSC-1, Security Configuration Compliance directs the use of security guides and STIGS. DISA and the National Security Agency have created lots of security guides for Windows and accompanying applications. Implementation of these guides will satisfy many of the other IA Controls.
http://iase.disa.mil/stigs/stig/index.html
IA Controls
The IA Controls will likely be most of the work you do on any system. Even if you have a MAC III, Public, there are a lot of them. They require everything from developing and/or checking documentation, installing security features, ensuring proper network configurations to checking personnel and physical security at each site. The DIACAP Knowledge Service has several templates detailing each group of IA Controls according to Mission Assurance Levels.
Continuity - COxx - IA Control
The COxx series of the IA Controls deal with the continuity of the system. Developing a comprehensive continuity, disaster recovery, emergency management plan for the system will satisfy many of the COxx IA Controls. Your division, squadron, flight or company will usually have some sort of emergency management plans and disaster recovery instructions you can use. The old DITSCAP System Security Authorization Agreement had Appendix L, Contingency Plan. Many of the requested documents and process likely already exist so it maybe a matter of just finding them or re-packaging them.
Security Design and Configuration - DCXX - IA Control
The DCxx series deals with designing and maintaining a secure baseline. Dealing with these IA Controls will require and intimate knowledge of the systems software, hardware, and network configuration. If you don’t know the configuration of the system you should have a highly knowledgeable technician or engineer on hand who does. You will need to know the DoD policy to understand what is fully required or if the control is even applicable. Network and computer security policies such as AFI-33-202 for the USAF will be a good help. Systems that have been developed outside of the DoD and US services policies will have a real hard time with these IA Controls.
Enclave Computing Environments - EVxx - IA Controls
Enclave computing environments are IA Controls that deal with security features within the local area network or enclave. It will help to have some understanding of network security because some of the IA Controls address things like VPN and Remote Authentication.
Identification & Authentication - IAxx - IA Controls
Identification & Authentication address specific issues that deal with logon and passwords.
Physical & Environment - PExx - IA Controls
Physical & Environmental IA Controls deal with physical security of the sites, safety issues and environmental controls such as humidity systems.
Personnel - PRxx - IA Controls
These IA Controls deal with the training and access of each personnel with direct contact with the system.
Vulnerability and Incident Management - Vixx - IA Controls
The issues in these few IA Controls maybe addressed in the contingency plan. Elements within DITSCAP System Security Authorization Agreement had Appendix K, Incident Response may also be used for these IA Controls.
POA&M: When Systems Can Not be Fix
Some legacy systems can not comply with applicable IA Controls without spending millions of dollars that the program office and/or system owners don’t currently have. In these cases it’s important to have a “get well plan”. The document is called a Plan of Action & Milestone (POA&M). The POA&M details what IA Controls have not been met, when they will and how. The EITDR eMASS system can automatically create a POA&M document once all the IA Controls have been entered, Validated and Approved (others eMASS systems might be able to do this as well).
Conduct Validation Activities
Validation includes Certification Test & Evaluation (CT&E) and Security Test & Evaluation (ST&E). Certification Test & Evaluation is completed on a system on which IA Controls have been applied in a test environment. The CT&E is conducted to make sure all the IA Controls have been applied on a functional system. Once has been proven to work in a testing environment with all the applicable technical IA Controls applied the ST&E can be completed with a system in an operational environment.
Techniques used in the CT&E and ST&E may include Gold Disk Scan, SRR (UNIX), penetration testing (black box, white box, gray box), network vulnerability scan, source code scan, web application scan, or simply a manual check of each of the security controls using the security guides. During and ST&E on the site it is also helpful to make sure there is proper contingency plans, physical & operational security.
DIACAP Activity #2 Reasonable:
POA&M (if applicable)
DIACAP Scorecard
Test Results
Popularity: 9% [?]
