DIACAP Activity #1 Initiate and Plan Certification & Accreditation

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
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)

Popularity: 9% [?]

NR-KPP stands for Net Ready Key Performance Parameters

Popularity: 4% [?]

ISP Architectural Views

One the most important part of an Information Support Plan(previously known as a C4ISP) is the Architectural Views.The DoD Architectural Framework Document describes each veiwin painful, painful detail.  Since the C4ISP has beenchanged into the ISP, the DoD Architectural Framework is abit out dated.  For example it doesn't mention “ISP” andalso includes some old views that have been phased out suchas OV-3 and SV-1.  The following gives my view on some ofthe views.

In my limited experience creating views is very interativeprocess. Meaning you create a little then your tweak andchange them as you go.

AV-1 Overview and Summary Information is a breeze if youhave all the appropriate information readily available.

Operation Views (OV)These are fun for me because I feel like I understandthem.  OV-1, High-level Operational Concept Graphic isone that I've had the pleasure of not having to do. Merely starting it was a bit of a challenge.  It isintended to look pretty. I've seen it done affectivelywith MS Word and PowerPoint.

OV-2 is Operation Node Connectivity.  As a network guy,this is my favorite.  I use Visio for this one withsimple shapes representing the nodes or you can getfancy and use computer Icons OV-4, OrganizationalRelationship Chart is another fun easy diagram that canbe created with Visio or Word using simple shapes. Ov-5 is the Activity Model.  Since it is so closelytied to SV-4, fuctional description and SV-5,Operational Activity to System Function TraceabilityMatrix, it is very, very interative and not one of myfavorites. I complete these three one after another. Both SV-4 and OV-5 must be completed before you do SV-5since all the info in SV-5 comes from those two.OV-6c, Operational Events-Trade Description requires avery good understanding of what happens to the dataupon entering the system.  But once you have thatnailed down it is fairly straight forward.  The logicaldata model, OV-7, can get a bit convoluted, I imagine. In it you are supposed give a visual representation ofthe various domains.

System Views (SV)The SV's can get a little gray as some of the views cantouch on things that involve your system but you haveperhaps only heard of.  For example, if your system “A”connects with System “B” you may have to show thatconnection even though you don't know much of anythingabout System “B”. I haven't seen SV-1 on the Teao Saicsite so I assume it has been phased out. But it dealswith Interfaces.  SV-2, System Communication Descriptionis very much like the example of system “A” in relationto “B”.  SV-2 shows how your system communicates/connectswith other systems.  Its almost like a birds eye veiw ofOV-2. SV-4, System Functionality Description, like I saidin the OV section closely related to OV-5 and SV-5.  Soif one changes, they may all have to change.SV-5 is a large table that shows the direct relationshipbetween Operational Activity to System Function.  It is apain in the ass for reason stated above. SV-6 can be avery complex table.  It is the System Data ExchangeMatrix.. you'll note that anything with the word “matrix”in it sucks.  That is because one change on a seperateveiw can affect change in other views and almost alwaysincludes the matrices.

Technical View (TV)TV-1, Technical Standards merely lists all the capabilitiesof the system and references each of the technical standardsused.

That is my oppinion of the ISP views.  I hope you find them as relatively painlessas I did and if not this site will help you out —>http://www.teao.saic.com/cbrtraining/archpro01.asp

Popularity: 2% [?]

Net Ready Key Performance Parameters (NR-KPP)

The Net Ready Key Performance Parameters (NR-KPP) is
comprised of the following elements: compliance with the Net-Centric
Operations and Warfare (NCOW) Reference Model (RM), applicable Global
Information Grid (GIG) Key Interface Profiles (KIP),
DOD information assurance requirements, and supporting integrated
architecture products required to assess information exchange and use
for a given capability.

Net Centric Operations Warfare Reference Model (NCOW RM) (a) The NCOW
RM serves as a common, enterprise-level, reference model for the DOD’s
Enterprise Architecture The NCOW RM will ultimately provide a common
architectural construct for NCOW with a common language and taxonomy.
The final version of the RM will include:

1. All Views (AV): AV-1 and AV-2
2. Operational Views (OV): OV-1, OV-2, OV-3, and OV-5
3. System Views (SV): SV-1, SV-2, SV-3, SV-4, and SV-5
4. Target Technical View

AV-1 Overview and Summary
Information Scope, purpose, intended users, environment depicted, analytical findings

OV-2 Operational Node
Connectivity Description Operational Nodes, operational activities performed at each node,
connectivity and information exchange need lines between nodes

OV-4 Organizational Relationships Chart
Organizational, role, or other relationships among organizations

OV-5 Operational Activity Model
Operational activities, relationships among activities, inputs and outputs.

OV-6c Operational Event-Trace Description
One of three products used to describe operational activity sequence and
timing – traces actions in a scenario or sequence of events and specifiestiming of events.

SV-4 Systems Functionality Description
Functions performed by systems and the information flow among system
functions, including information assurance functions

SV-5 Operational Activity to Systems Function Traceability Matrix
Mapping of systems back to operational capabilities or of system functions
back to operational activities.

SV-6 Systems Data Exchange Matrix
Provides details of systems data being exchanged between systems.

TV-1 Technical Standards Profile Extraction of standards that apply to the given architecture,
Including information assurance functions.

Bookmarks
that are constantly updated by people around the world use delicious
feed for netcentric (will need an aggregator to view feed):

http://del.icio.us/rss/tag/netcentric
More on Netcentrics, Ditscap, DIACAP and Information Assurance at infoassure.blogspot.com

Popularity: 5% [?]