IA Control Typo: DCSQ-1 Unix SRR script
March 13, 2008
Alex of Le Blog d’Alex
had a good question:
Looking at Unix SRR scripts (January 08 release) I’ve found some PDI’s (vulnerabilities) corresponding to IA control number “DSCQ-1″, which I cannot find in DoD Instructions 8500.2 Feb 6 2003 (neither appears the DSxx Subject Area in table E4.T1.).
Do you know what Subject Area corresponds to DSxx? And what IA control is DSCQ-1?
I’ve googled for it and I can’t find anything neither.
If you answer, please would you mind answering also by email? Thanks by advance.
I don’t think there is a DSCQ. In fact there is no DSXX series of IA Controls. I think that is a typo in the Unix SRR script. A Unix guru security co-worker of mine has found other minor typo’s in the script as well as tons of false positives.
It looks like the script is actually refering to “DCSQ-1″. Looks like they swapped the “CS”
Software quality requirements and validation methods
that are focused on the minimization of flawed or malformed
software that can negatively impact integrity or availability
(e.g., buffer overruns) are specified for all software
development initiatives.
–DoD 8500.2
If this is not the case than I really don’t know what DCSQ could be.
Popularity: 5% [?]
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: 5% [?]
ATO and ATC
February 11, 2008
Difference between DITSCAP and DIACAP ATO:
Although the acronym “ATO” was used in DITSCAP and is now being used in the DIACAP process, the DIACAP ATO is “Authority to Operate” and replaces the DITSCAP “Approval to Operate”. The essential meaning is the same. An ATO is still a statement that marks a formal Accreditation Decision issued by the DAA.
E2.2. Accreditation Decision. A formal statement by a designated accrediting authority (DAA) regarding acceptance of the risk associated with operating a DoD information system (IS) and expressed as an authorization to operate (ATO), interim ATO (IATO), interim authorization to test (IATT), or denial of ATO (DATO). The accreditation decision may be issued in hard copy with a traditional signature or issued electronically signed with a DoD public key infrastructure (PKI)-certified digital signature. (DOD 8510.01)
E2.8. Authorization to Operate (ATO). Authorization granted by a DAA for a DoD IS to process, store, or transmit information. An ATO indicates a DoD IS has adequately implemented all assigned IA controls to the point where residual risk is acceptable to the DAA. ATOs may be issued for up to 3 years. (DOD 8510.01)
E2.19. Designated Accrediting Authority (DAA). The official with the authority to formally assume responsibility for operating a system at an acceptable level of risk. This term is synonymous with designated approving authority and delegated accrediting authority. (Reference (d) leads with the term designated approving authority, which was favored at the time of publication.). (DOD 8510.01)
Connection to the NIPRNet/GIG:
To connect to the Global Information Grid (which includes the NIPRNet/SIPRNet) an Approval To Connect is need.
Authority to Connect (ATC). The ATC defines the customer’s connection boundaries as accepted by the DISN SIPRNET Management and reflects the completion of a successful network vulnerability assessment by the DISA SCAO. CJCSI 6211.02B 31 July 2003
Interim Approval to Connect (IATC). The IATC defines the customer’s connection boundaries as accepted by the DISN SIPRNET Management. CJCSI 6211.02B 31 July 2003
Popularity: 4% [?]
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: 4% [?]
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: 4% [?]
DIACAP Activity #3 Make Certification Determination and Accreditation Decision
February 4, 2008
Once all of the validations have been complete its time for the IA Component to make a certification determination. They examine the system and may call for additional documentation to verify certain IA features. Waivers, memoradums and other documentation may be required for completion of the certification. The IA Component may need additional scan results. This can sometimes make the process much longer than it should be.
Issue Accreditation Decision
Once the all documentation and scans for the certification have been completed it is out of your hands. The IA Component will push the package forward for final Accreditation approval. The DAA usually takes the recommendations of the IA Component so its best to have complied with all of their wishes.
The DAA will issue an ATO, IATO, ATC or IATC.
E2.2. Accreditation Decision. A formal statement by a designated accrediting authority (DAA) regarding acceptance of the risk associated with operating a DoD information system (IS) and expressed as an authorization to operate (ATO), interim ATO (IATO), interim authorization to test (IATT), or denial of ATO (DATO). The accreditation decision may be issued in hard copy with a traditional signature or issued electronically signed with a DoD public key infrastructure (PKI)-certified digital signature. (DOD 8510.1)
More on ATOs & ATC’s
Popularity: 3% [?]
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: 5% [?]
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: 3% [?]
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: 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: 7% [?]
