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% [?]
DIACAP Activity #1 Initiate and Plan Certification & Accreditation
February 2, 2008
Initiating the
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
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
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
DoDI 8551.1, “Ports, Protocols, and Services Management (PPSM) Release 6.9,” dated September, 2007
DoDI 8570.1-M “Information Assurance Workforce Improvement Program,” dated December 19, 2005
Federal Information Security Management Act (FISMA) (2002)
Information Assurance Support Environment (IASE)
Popularity: 9% [?]
The ISSEP: Information System Security Engineering Professional (ISSEP) certification
September 14, 2005
I've been thinking of taking the Information System Security Engineering Professional (ISSEP) certification. Since the CISSP info is still fresh in my mind and much of the ISSEP are things I do or have to deal with daily it seems like a good idea.
What is the ISSEP?
The ISSEP was developed by the International Information System Security Certification Consortium (ISC)2 in conjuction with the National Security Agency/IAD. Where as the CISSP is an all encompassing general look at security, the ISSEP is a concentration on system security engineering process. System security engineering has to do with ensuring that selected solutions
meet the mission or business security needs. It is defined as “the art of and science of discovering users security needs, and designing and making with economy and elegance information
systems so that they can safely resist the forces they might be subjected to.”
System Security Engineers tasks:
Discover Information Protection Needs
Define system Security Requirements
Design System Security Architectures
Develop Detailed Security Design
Implement System Security
Assess Information Protection Effectiveness
Instead of ten Domains the ISSEP has four:
System Security Engineering
Certification and Accreditation
Technical Managment
U.S. Government Information Assurance Regulations
Most of of the ISSEP's material comes from the Information Assurance Technical Framework (IATF).
My co-worker recently took the test and he said it was more difficult than the CISSP. The CISSP is easily THE most difficult test I've every done. Although, since most of the information comes from the IATF, I'm not sure how it could be more difficult.
The CISSP is so broad that you could not possibly get all the information from a single source.
http://www.acsac.org/2003/case/thu-c-1530-Oren.pdf
www.nsa.gov
www.isc2.org
Popularity: 7% [?]
Net Ready Key Performance Parameters (NR-KPP)
June 26, 2005
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% [?]
SSAA vs. ISP
June 26, 2005
I've done a few System Security Authorization Agreements (SSAA's) but I
admit I'm doing Information Support Plans, ISPs (formerly C4ISPs) for
the first time.
I used to think that the SSAA was a little bit
too much information. Overtime I've learned that it make total sense.
It forces the Information System designers to answer important questions. Many times the
questions it answers aren't important until much later (such as life
cycle issues).
The ISP's puts the SSAA to shame in its sheer
volume of information that needs to be gathered. This is because it
includes the netcentric aspects of the system, the actual schedule and
money involved, acquisitions issues and a bunch of other things that I,
as a security guy, don't care about.
The ISP is a birds eye view
of the target system where the SSAA is a microscope into all levels of
security over the life of the system from cradle to the grave.
More on Information Assurace, DITSCAP, and DIACAP on infoassure.blogharbor.com
Popularity: 3% [?]
