Assurance, Assurance/DIACAP, Assurance/DITSCAP, Assurance/Netcentric, Assurance/SSAA, C&A, Computer Security, DIARMF, DoD Risk Management Framework, DoD RMF, EITDR, FISMA, Main Digg, nist, Risk Management Framework, security, Security Awareness, Security Awareness/ISSA
Who Creates and/or Manages the NIST 800?
This NIST 800 is a well thought out set of federal security standards that DoD and the Intel world is moving too. It aligns with International Organization for Standardization (ISO) and International Electotechnical Commissions (IEC) 27001:2005, Information Security Management System (ISMS).
NIST 800 is updated and revised by the following organizations:
Joint Task Force Transformation Initiative Interagency (JTFTI) Working Group National Institute of Standards and Technology (NIST)
JTFTI is made up of from the Civil, Defense, and Intelligence Communities. This working group reviews and updates the following documents
- NIST Special Publication 800-37, Revision 1 Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach
- NIST Special Publication 800-39, Enterprise-Wide Risk Management: Organization, Mission, and Information Systems View
- NIST Special Publication 800-53, Revision 3 Recommended Security Controls for Federal Information Systems and Organizations
- NIST Special Publication 800-53A, Revision 1 Guide for Assessing the Security Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans
These core documents are a standard on how to implement FISMA. The organization has done a good job of keeping NIST 800 inline with international standards of ISO 27001. The JTFTI is made up of ODNI, DoD, CNSS. This document is also publicly vetted.
Office of the Director of National Intelligence (ODNI)
The DNI is a position required by Intelligence Reform and Terrorism Prevention Act of 2004. This office serves as adviser to the president, Homeland Security and National Security Counsil as well and director of National Intelligence.
Department of Defense (DoD)
DoD is composed of (but not limited to) the USAF, US Army, DON and Marines. It is the most powerful military organization in recorded history.
Committee on National Security Systems (CNSS)
This committee was created to satisfy National Security Directive 42, “National Policy for the Security of National Security Telecommunications and Information Systems“,
the group has represtatives from NSA, CIA, FBI, DOD, DOJ, DIA and is focused on protecting the US crititcal infrastructure.
Public (review and vetting) – the draft is posted online on NIST.gov
Scadahacker – mappings NIST to International
I stumbled upon your site and am new to security working for a contractor. I’m attempting to complete a DIACAP POA&M and need to map SRR findings to IA controls – any idea where I might find this information?
The SRR finding reference the DOD Unix STIG
and NIPR STIG. It doesn’t seem to completely match up the the DIACAP IA Controls, but that is where a good system security engineer/ IA analyst comes in.
Once you’ve got your SRR results, IA Control compliance and mitigation depends on your situation. There are a few that map directly (like Screen Saver) but most of the SRR findings will fall under one or two of the IA Controls.
Hope this helps.
UPDAT: 2014 - Risk Management Framework for DOD IT released.
Day 3 heats up a little. We start talking about what it take to actually get validated. The DIACAP Implementers Guide & the DIACAP Validators guide is opened up and reviewed. I think we all learned a little something during this discussion because there have been some challenges with this. Unfortunately, we don’t to far into the validator stuff.
Assurance, Assurance/DIACAP, Assurance/DITSCAP, Assurance/Netcentric, Assurance/SSAA, Certification/CISSP, EITDR, federal, FISMA, information assurance, Main Digg, security
Assemble DIACAP Team
Registered System/System Information Profile
Assign IA Controls
Initiate DIACAP Implementation Plan
DIACAP/AFCAP Day 1.
This is the second installment of the DIACAP Essentials journal.
In the first day of class we’ve taken a high level look at the big picture of the Department of Defense Information Assurance Certification & Accreditation Process (DIACAP) and Air Force Certification & Accreditation Program (AFCAP). It is a very valuable tool for a beginner.
Since I’ve gone through the entire process (with a legacy system) more than once through all the growing pains of Air Force C&A from DITSCAP to DIACAP, I found that I knew about 90% of everything taught. I don’t mind having a refresher, though and quite frankly, I need the CPE’s for my CISSP :).
There were a couple of golden nuggets that I’ve been able to get out of some of the old timers. I learned some interesting things about how the Navy, Marines and Army do things.
Navy (as weird as their dumb ass rank system.. yep, I said it.. its dumb) have like three systems: DITPR-DON, DA-DUMB and some other BS, Marines have something called Exacta and the Army has APMS (Army Profile Management System). Also learned cool off topic stuff like history of eMass.
I must admit I’m looking forward to day two.
pros of day 1: Good solid start on basics GREAT for beginners. SecureInfo gets mad props for have a great instructor John M.(don’t know if he wants his full name published.. but he’s highly, highly knowledgeable and very positive).
cons of day 1: Right off the bat I am noticing a huge hole in the training… a lack of in depth teaching of EITDR, which is how the Air Force implements, manages and maintains the entire DIACAP/AFCAP process. I don’t really see how you can teach one without the other these days. I guess contractually, SecureInfo can not touch it since some other company has the contract. But unfortunately, the folks that are new to this are going to suffer. Because if they goto this class without knowing the EITDR they will know why but now how, and if they go to the EITDR class without knowing the DIACAP they will know how but not Why.
To the family of Kyu H. Chay,
I am sorry for your loss, but I thank you for your sacrifice. Kyu H. Chay is more that just an American hero, he represents the best of what we are capable of. He was a father, a husband and a protector of soldiers. I hope Jason and Kelly know how special their father is.
Certification and accreditation process for national security systems to extend to the rest of government. A two-year-old effort to standardize processes for certifying and accrediting government IT systems could soon bear fruit, according to officials from several agencies.
The Committee on National Security Systems is preparing instructions for implementing a unified certification and accreditation (C&A) process that could be used on all national security systems, including those in the Defense Department and intelligence community, said Tony Cornish, chairman of the CNSS’ C&A working group.
At the same time, the National Institute of Standards and Technology plans to update its C&A guidance for systems covered by the Federal Information Security Management Act, said Ron Ross, a senior computer scientist and FISMA implementation lead at NIST.
“We are very close to producing a unified C&A process for the entire federal government,” Ross said in July at a government security symposium hosted by Symantec. “Within the next six to eight months, you are going to see a plethora of new things coming out” from CNSS and NIST.
CNSS’ instructions will be incorporated into NIST guidelines in its 800 series of special publications. Ross said a major update of SP 800-53 Rev. 2, “Recommended Security Controls for Federal Information Systems,” is expected in December, and a draft of the first revision of SP 800-37, “Guide for the Security Certification and Accreditation of Federal Information Systems,” is expected to be released for comment soon.
A single, governmentwide approach would make it easier for agencies to share data and cooperate with one another and with states, foreign allies and the private sector.
It could enable reciprocity, or the acceptance of other agencies’ C&A processes, without requiring recertification, and also could streamline acquisition processes by making it easier for vendors and developers to meet one set of standards.
C&A is a process for ensuring that IT systems are operating with an appropriate level of security. In the certification phase, the security of the system is documented; for accreditation, a designated authority signs off on the system’s fitness to go into operation. The concept has been around for some time, but there has been little standardization.
“In the past, we each had our own set of policies, and we didn’t look at each other’s,” said Sherrill Nicely, deputy associate director of national intelligence at the Office of the Director of National Intelligence.
FISMA requires C&A of information technology systems, but that does not apply to national security systems. And within the national security community, the military and intelligence sectors each have had their own way of doing things.
“Since about 1993, the Defense Department had its program, the Defense IT Security Certification and Accreditation Process,” said Eustace King, DOD chief of acquisition and technology oversight. “It worked pretty well” in a time before DOD’s emphasis on network- centric systems and information sharing, but it lacked enterprise visibility.
That C&A program was replaced with the Defense Information Assurance Certification and Accreditation Process. DOD was moving to the program in 2006 to harmonize military and intelligence processes when, a year later, it was expanded to include the rest of the national security community by bringing in the CNSS.
Through NIST, C&A procedures eventually will be standardized across all of government. However, policies do not change mind-sets, and old habits still remain one of the primary challenges to a standardized process. At DOD, there is a reluctance to accept reciprocity — that is, to give full credit to another agency’s C&A process without recertification, King said.
The intelligence community faces a similar hurdle, said Sharon Ehlers, an assistant deputy associate director of national intelligence.
“The cultural change has been the biggest challenge,” Ehlers said. “When it is not invented here, people don’t want to look at it.”
Product Definition. Operational Activity to Systems Function Traceability Matrix is a specification of the relationships between the set of operational activities applicable to an architecture and the set of system functions applicable to that architecture.
Product Purpose. SV-5 depicts the mapping of operational activities to system functions and thus identifies the transformation of an operational need into a purposeful action performed by a system.
SV-5 can be extended to depict the mapping of capabilities to operational activities, operational activities to system functions, system functions to systems, and thus relates the capabilities to the systems that support them. Such a matrix allows decision makers and planners to quickly identify stovepiped systems, redundant/duplicative systems, gaps in capability, and possible future investment strategies all in accordance with the time stamp given to the architecture. SV-5 correlates capability requirements that would not be satisfied if a specific system is not fielded to a specific DoD unit.
Product Detailed Description. The Framework uses the terms activity in the OVs and function in the SVs to refer to essentially the same kind of thing-both activities and functions are tasks that are performed, accept inputs, and develop outputs. The distinction lies in the fact that system functions are executed by automated systems, while operational activities describe business operations that may be conducted by humans, automated systems, or both. Typical systems engineering practices use both of these terms, often interchangeably. However, given the Framework’s use of activities on the operational side and functions on the systems side, and the fact that operational nodes do not map one-to-one to systems nodes, it is natural that operational activities do not map one-to-one to system functions. Therefore, SV-5 forms an integral part of the eventual complete mapping from operational capabilities to systems requirements. SV-5 is an explicit link between the OV and SV. The capabilities and activities are drawn from OV-5, OV-6b, and OV-6c. The system functions are drawn from an SV-4. (SV-1 and SV-2 may also define system functions for identified systems.)
The relationship between operational activities and system functions can also be expected to be many-to- many (i.e., one operational activity may be supported by multiple system functions, and one system function may support multiple operational activities).
Product Definition. The Systems Functionality Description documents system functional hierarchies and system functions, and the system data flows between them. Although there is a correlation between Operational Activity Model (OV-5) or business-process hierarchies and the system functional hierarchy of SV-4, it need not be a one-to-one mapping, hence, the need for the Operational Activity to Systems Function Traceability Matrix (SV-5), which provides that mapping.
Product Purpose. The primary purposes of SV-4 are to (a) develop a clear description of the necessary system data flows that are input (consumed) by and output (produced) by each system, (b) ensure that the functional connectivity is complete (i.e., that a system’s required inputs are all satisfied), and (c) ensure that the functional decomposition reaches an appropriate level of detail.
Product Detailed Description. SV-4 describes system functions and the flow of system data among system functions. It is the SV counterpart to OV-5. SV-4 may be represented in a format similar to data flow diagrams (DFDs) [DeMarco, 1979]. The scope of this product may be enterprise wide, without regard to which systems perform which functions, or it may be system specific. Variations may focus on intranodal system data flow, internodal system data flow, system data flow without node considerations, function to system allocations, and function to node allocations.
The system functions documented in the SV-4 may be identified using the Service Component Reference Model (SRM),20 or some other system function taxonomy, and correlated to SV-1 and SV-2 systems. System functions are not limited to internal system functions and can include Human Computer Interface (HCI) and Graphical User Interface (GUI) functions or functions that consume or produce system data from/to system functions that belong to external systems. The external system data sources and/or sinks can be used to represent the human that interacts with the system or external systems. The system data flows between the external system data source/sink (representing the human or system) and the HCI, GUI, or interface function can be used to represent human-system interactions, or system-system interfaces. Standards that apply to system functions, such as HCI and GUI standards, are also specified in this product.
Like OV-5, SV-4 may be hierarchical in nature and may have both a hierarchy or decomposition model and a system data flow model. The hierarchy model documents a functional decomposition. The functions decomposed are system functions.
Initiating the Department of Defense Information Assurance Certification & Accreditation Process (DIACAP) starts with a lot of “setting up shop”. Registering with a DoD component, forming the IA Team and assigning IA controls (also known as IA requirements and security controls) can be a lot of work, but the more of these tasks you complete, the easier the rest of the process will be.
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
*more on Army NETCOM
More on Registering with your IA Component
Once you’ve made contact with your system’s IA Component you may be asked to identify the players in your DIACAP Team. The DIACAP Team roles will consist of a Designated Approval Authority (DAA), Program Manager (PM), Certifying Authority (CA), User Rep, Information Assurance Manager and others. You will also need to identify other important players such as the Lead Engineer.
More on DIACAP Team Roles.
Get an Enterprise Mission Assurance Support Service (eMASS) account
The Enterprise Mission Assurance Support Service (eMASS) is a generic name for specific automated databases that are used to manage the DIACAP. Each branch has a different automated database (Fig 1). The USAF has the EITDR, The Navy has the DITPR-DON, and the Army has the APMS. Each of these databases satisfies DoD IT portfolio management, certification and IT reporting directives addressed in DoD Directive 8115.01, signed October 10, 2005.
Fig 1, DoD IT Portfolio Management System
More on the eMASS systems.
Assign IA Controls
Information Assurance Controls are also known as Information Assurance requirements and security controls. IA Controls are assigned according to a system’s Mission Assurance Category (MAC) and Confidentiality Levels (Fig 2.) defined in DoDI 8500.2. The DIACAP Knowledge Service has Excel spread sheets breaking down each of the IA Controls.
Fig. 2, Mission Assurance Category & Confidentiality Levels
Some of the IA Controls require system security engineering interpretation because no system is alike. Some IA Controls will not apply while other will apply only under certain circumstances and that is where knowledgeable system & system security engineer comes in.
DoDI 8500.2, Enclosure 4
Initiate DIACAP Implementation Plan
With the proper MAC/CL level applied, the system security specialist/engineer and/or technician should have a good idea what IA Controls apply to a given system. The next step is to begin the DIACAP Implementation Plan.
The DIACAP Knowledge Service has a thorough break down of each of the IA Controls and how to accomplish and validate them. Once complete, your system’s DIACAP Implementation Plan should identify each of the applicable IA Controls, whether the system is compliant or not and when it will be compliant with those particular IA Controls.
Initiation of the DIACAP Plan means you are consulting developers and or Program Managers on the IA Controls that will affect the system. Both new systems, and existing legacy systems will require some sort of documentation whether a simple spreadsheet, or Word document detailing who, what, when and where of each IA Control feature applied to the system. The DIACAP Knowledge Service has a sample DIACAP Implementation Plan spread sheet that thoroughly details all the above requirements. It can be downloaded and tailored easily to your specific systems needs.
Once registered, the eMASS (EITDR, DITPR-DON, and APFM) system will require that you upload your completed DIACAP Implementation Plan (which is a bit of a paradox because the EITDR can actually create a DIACAP package once certain data is uploaded, validated and approved. EITDR will also require that the IA Controls be addressed and validated individually and subsequently Reviewed, Validated and Approved by system stakeholders.
Deliverables for Activity #1:DIACAP System Identification Profile (SIP)
DIACAP Implementation Plan
USAF SISSU Stakeholder’s List (Air Force)
DoD Regulation 5200.1-R , “DoD Information Security Program,” January 1997
DoDD 8115.01, “Information Technology Portfolio Management”, dated October 10, 2005
DoDD 8500.01E, “Information Assurance (IA),” dated April 23, 2007
DoD 8510.1-M, “DoD Information Technology Security Certification and Accreditation Process (DITSCAP) Application Document”, dated July 31, 2000
DoDI 8551.1, “Ports, Protocols, and Services Management (PPSM) Release 6.9,” dated September, 2007
DoDD 8570.1, “Information Assurance Training, Certification, and Workforce Management,” dated August 15, 2004
DoDI 8570.1-M “Information Assurance Workforce Improvement Program,” dated December 19, 2005
Deputy Secretary of Defense Memorandum, “Information Technology Portfolio Management,” March 22, 2004
Federal Information Security Management Act (FISMA) (2002)
Information Assurance Support Environment (IASE)