Risk Assessments and Risk Management will apply to National Security Systems (NSS).

What is a Risk Assessment?

A risk assessment is the results/process to determine the likelihood that a threat will exploit a weakness. Risk assessment is a part of the risk management.

What is risk management?

Risk Management is the on-going process of determining assessing, identifying and prioritizing of risks.

Is My System a National Security System?

NIST SP 800-59, Guidance for Identifying an information system as an NSS. 800-39 is a 17 page document developed in conjunction with the Department of Defense, including the National Security Agency, for identifying an information system as a national security system. It is basised on the Federal Information Security Management Act of 2002 (FISMA).

Who determines if you have an NSS?

The head of each agency is responsible for designating an agency information security official to determine which, if any, agency systems are national security systems.

Tools to determine if you have a NSS system:

National Security System Identification Checklist (NIST SP 800-59, Appendix A). The NSS ID Checklist asks (6) questions. Answering yes to any of these questions qualifies your system as an NSS:
• Does the function, operation, or use of the system involve intelligence activities?
• Does the function, operation, or use of the system involve cryptologic activities related to national security?
• Does the function, operation, or use of the system involve command and control of military forces?
• Does the function, operation, or use of the system involve equipment that is an integral part of a weapon or weapons system?
• Is the system critical to the direct fulfillment of military or intelligence missions?
• Does the system store, process, or communicate classified information?

NSS RMF
The guidance of CNSSI 1253 is the result of NIST collaborated with the Intelligence Community (IC), Department of Defense (DoD), and the Committee on National Security Systems (CNSS) to ensure NIST SP 800-53 contains security controls to meet the requirements of National Security Systems (NSS).

KEY DIFFERENCES BETWEEN CNSS INSTRUCTION NO. 1253 AND NIST PUBLICATIONS

The key differences between CNSSI 1253 and the rest of the NIST publications is that NSS systems do not follow “high-water mark”, NSS maybe tailored through risk-based adjustment, control profiles, and a method that allows organization to practice reciprocity.

NSS and High Water Mark
Both FIPS 200 and NIST 800-53 apply the concept of a high-water mark (HWM) when categorizing information systems according to the worst-case potential impact of a loss of confidentiality, integrity, or availability of information or an information system. This Instruction does not adopt this HWM usage. In the National Security Community, the potential impact levels determined for confidentiality, integrity, and availability are retained, meaning there are 27 possible three-value combinations for NSI or NSS, as opposed to the three possible single-value categorizations obtained using the guidelines in FIPS 200. – CNSSI 1253

Risk-Based Adjustment
Potential impact-based security categorizations for NSS may be tailored through the use of a risk-based adjustment. This adjustment takes into consideration the physical and personnel security measures already employed throughout the National Security Community and factors such as aggregation of information.

Control Profile
Method by which organizations may designate sets of controls for NSS based on their enterprise-wide risk assessment and taking into account business objectives, system risks, and mission needs.

NSS Reciprocity
It is the policy of the National Security Community that member organizations practice reciprocity with respect to the certification of systems and system components to the greatest extent practicable. Reciprocity of certification reduces the cost and time to implement systems and system components.

If the transition is anything like their move to from DoD Information Technology Security Certification & Accreditation Process (DITSCAP) to the DIACAP then they will give about 2 years for the DoD to transition. As of Mar. 2011, there is no policy on this. It is serious because its on the DIACAP KS and the Department of Navy CIO has been releasing information on it since 2009. The DON CIO & the ASD (NII) have been working on the project to transition from DIACAP to some sort of DoD Risk Management Framework. So far, they have mapped the DoDI 8500.2 IA controls to the NIST SP 800-53 Controls: Certification and Accreditation Transformation: Security Control Mapping. Here is a May 2010 update to the NIST to DIACAP mapping. 800-53 to DoD IA contols map also includes the Director of Central Intelligence Directive (DCID) 6/3 controls. This is very telling. The plan seems to be to have one standard for all Federal Information System.

Since DoD 8510.01, DIACAP & NIST SP 800-37, Risk Management Framework (RMF) cover so much of the same ground, I think the only real benefit is that reciprocity between Federal agency will be easier if all departments have one standard of risk management and one security control set.

The DON uses the certification and accreditation (C&A) process to assess and understand the residual risk associated with operating information systems (IS) and information technology (IT). The DON is participating with the DoD, the IC, and the rest of the Federal government in C&A transformation. One goal of transformation is to achieve common security controls enabling the DON, the DoD, the IC, and the rest of the Federal government to develop systems to the same protection standards.

The recently released National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, revision 3 provides recommended consolidated security controls in an effort to achieve common security controls across the Federal government.

The DON will continue to use the DoDI 8500.2 as the authoritative source for security controls until otherwise specified. However, understanding the changes represented in NIST SP 800-53r3 will be essential as DoD and the DON begin transitioning to this new set of security controls. To support the transition, the DON CIO developed this security control mapping document to demonstrate how existing DoD and IC security controls map to the security controls recommended by the NIST SP 800-53r3 publication.

–Security Control Mapping Document Aids Transition, DON CIO Site

The DoD has had the same IA controls since DoD 8510.1-M, controls since DoD 8510.1-M, Department of Defense Information Technology System Certification & Accreditation Process (DITSCAP), July 31, 2000 – it was developed late last century.

The DoD has a total of 157 IA controls spread across 8 subject areas in 4 classes:

DC – Security Design & Configuration

IA – Identification and Authentication

EC – Enclave & Computing

EB – Enclave Boundary Defense

PE – Physical & Environmental

PR – Personnel

CO – Continuity

VI – Vulnerability

There is a huge change coming in certification & accreditation for the DoD coming. The IA controls are being expanded and changed. The last two DIACAP classes I’ve been to mentioned that there is a big change coming. Essentially, all the IA Controls (security controls, safeguards, countermeasures.. whatever your organization is calling them) are getting expanded. All federal organizations will have security controls that look more like what is in the National Institute of Standards and Technology Special Publication 800-53. This is all being placed in the Committee on National Security Systems Instruction (CNSSI) 1253. As of 25 June 2009, the CNSSI 1253 is still in draft.

The draft has 17 families & identifiers in three security control classes.

TABLE 1: SECURITY CONTROL CLASSES, FAMILIES, AND IDENTIFIERS
IDENTIFIER FAMILY CLASS

AC Access Control Technical

AT Awareness and Training Operational

AU Audit and Accountability Technical

CA Certification, Accreditation, and Security Assessments Management

CM Configuration Management Operational

CP Contingency Planning Operational

IA Identification and Authentication Technical

IR Incident Response Operational

MA Maintenance Operational

MP Media Protection Operational

PE Physical and Environmental Protection Operational

PL Planning Management

PS Personnel Security Operational

RA Risk Assessment Management

SA System and Services Acquisition Management

SC System and Communications Protection Technical

The CNSSI has about 500 controls with pretty good granularity.

One of the really cool thing about 1253 was the security control mapping. It’s a table that matches up 800-53, DCID 6/3 and DODI 8500.2.

Stuff I learned from people in the class:

-AFCA is changing its name (to what?)

DOD is going to put the new IA controls in NCSSI 12-53 (currently in draft)

-a lot of what I need in there is in NIST 800-53

Marines use something called Exacta

Site called securitycritics.org

33-202 is now completely irrelevant and obsolete (not even mentioned ONCE in the class)

800-30

Feds call Certification &Accreditation (C&A) “Security authorization”

NIST SP 800-37

Day 4:

Validator Activities & Issue Accreditation Decision

Prepare POA&M

Validate Results/Scorecard

Scorecard

Make certification determination

CA/DAA Package review

Day 5:

Validation procedures were discussed. On day five, we looked at how the validators look at a system.

I thought is was interesting. It should help me get through the EITDR/DIACAP process easier.

Maintain Situational Awareness

Maintain IA Posture

Conduct Review

R-Accreditation

Retire system

Day 3:

DIACAP Structure

Terminology Review

Assemble DIACAP Team

Registered System/System Information Profile

Assign IA Controls

Initiate DIACAP Implementation Plan

Day 1 &2:

Getting the Big Picture

DIACAP/AFCAP Policy & Terminology

Roles and Responsibilities for the C&A process

Accreditation & Approval to Connect

Homework: review terminology

In between longer breaks, during lunch and just before class we sneak in episode of the The IT Crowd. Its the first time I’ve watched it so its a real treat for me. Hilarious show.

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.

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
DIACAP Team

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.

Ref:

https://akss.dau.mil/dag/GuideBook/IG_c7.5.7.2.asp

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)

References:

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)

So Net Ready Key Performance Parameters refers to evaluating the “net readiness” of a given information system or organization.

Formal Definition:
NR-KPP was developed to assess net-ready attributes required for both the technical exchange of information and the end-to-end operational effectiveness of that exchange. The NR-KPP replaces the Interoperability KPP, and incorporates net-centric concepts for achieving Information Technology (IT) and National Security System (NSS) interoperability and supportability.

What are the elements within the Net Ready Key Performance Parameters?

Net Centric Operations and Warfare Reference Model (NCOW RM) Compliance Statement

Information Assurance (IA) Accreditation Compliance Statement

Your guide on creating the NR-KPP will be the CJCSI 6212, Interoperability and Supportability on National Security Systems:

Net-Ready Key Performance Parameter. All Information Support Plans (ISP) for systems that exchange information with other systems will contain a Net-Ready KPP. For all ISPs with an associated approved JCIDS CDD or CPD capabilities document, the ISP can refer to the associated CDD/CPD. ISPs for CRDs, ORDs, non-ACAT and fielded systems will include the NR-KPP in the ISP.

The NR-KPP will consist of the following:
a. AV-1, OV-2, OV-4, OV-5, OV-6C
b. SV-4, SV-5, SV-6
c. TV-1 generated from DISR online
d. Applicable CRD crosswalk (See Table D-3)
e. Initial LISI Profile (Interface Requirements Profile) See Enclosure K
f. NR-KPP statement. (Table I-1)
g. IA Statement of Compliance
h. Key Interface Profile (KIP) Declaration (list of the KIPS that apply to
the system)

Key Interface Profiles (KIPs) Compliance Statement

Reference:
CJCSI 6212, Interoperability and Supportability on National Security Systems
ß http://www.teao.saic.com/cbrtraining/docs/CJCSI_6212_01.pdf

Net Ready -> http://del.icio.us/tag/%22net%2Bready%22
More on NR-KPP à http://del.icio.us/tag/%22nr%2Bkpp%22

http://del.icio.us/rss/tag/netcentric