DIACAP to DIARMF: Assessment Authorization

DIACAP to DIARMF: Assessment Authorization

DIACAP to DIARMF: Assessment Authorization

With the move from certification and accreditation (C&A) to risk management framework, comes a few new terms.  “C&A” will be replaced with assessment and authorization.  Even though “information assurance (IA) controls” will be call “security controls”, the definition and work is still the same, but the hope is that its done continuously and more cost-effective.


Certification (NIST Assessment) – Comprehensive evaluation of an information system assessment of IA Controls/Security Controls to determine the extent to which the controls are implemented correctly and operating as intended. That means when evaluated, they produce the desired outcome.  An assessment is about gathering information to providing the factual basis for an authorizing official (Designated Accrediting Authority) to render a security accreditation decision

Accreditation (NIST Authorization) – Security accreditation is the official management decision to operate (DAA – Formal approval of the system). Authorization is given by a senior agency official (upper-management/higher head quarters/combat commander). The official should have the authority to oversee the budget and business operations of the information system explicitly accept the risk to operations, assets, individuals. They accept responsibility for the security of the system and are fully accountable for the security of the system.

The official management decision given by a senior organization“The official management decision given by a senior organizational official to authorize operation of an information system and to explicitly accept the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security controls.”

– NIST SP 800-37 rev 1

March 14, 2014, UPDATE RMF – DoD IT:

DIARMF will be known as Risk Management Framework for DoD IT.


diacap diarmf

diacap to diarmf: intro


diacap diarmf

image of diacap to rmf

DoD Chief Information Officer (formerly Assistant Security Defense), in collaboration with the Department of the Navy CIO, has developed a DoDI 8500.2 to NIST SP 800-53 IA control mapping (2010). More DIACAP Knowledge Service.

DIACAP Knowledge Service

On the DIACAP Knowledge Service goto “C&A Transformation”. This page introduces some of the coming changes from Certification & Accreditation changes to the Risk Management Framework seen in NIST SP 800-37.

DIACAP has “Risk Management Framework Transformation Initiative” underway that provides information on use of NIST SP 800-53, NIST SP 800-37, CNSS Instruction 1253.

The site introduces changes being made to DoDD 8500.01, DoDI 8500.2, DoDI 8510.01 and other documents that will be aligned with NIST 800 and FISMA 2013. They will feature an attempt to keep up with new arising cyberthreats, vulnerabilites and security incidence using real-time, “continuous monitoring” technologies such as HP ArcSight, McAfee ESM, ePO, NSP, Retina, Nessuss and other near real-time active monitoring systems.

diacap to diarmf

road to diarmf


Federal government has gotten more serious about security.  They realize that enterprise level security and process is a continuous and expensive business.  The old certification & accreditation process is not only long and expensive but so slow that it cannot keep up with the constant changes of information technology.

Risk based/cost effective security means creating security systems and policies that focus on “adequate security”.  The Executive Branch Office of Management and Budget (OMB) defines as adequate security, or security commensurate with risk, to include the magnitude of harm resulting from the unauthorized access, use, disclosure, disruption, modification, or destruction of information.  The feds are also attempting to make the process of implementing and evaluating security controls by creating as much paper-less automation as possible.

note IMHO: Since technology is changing at a rate of what Ray Kurzweil calls “accelerating returns” I think for governments and organizations stuck in “static policy” based systems there is no way they can ever keep up with information technology without revolutionary shift in thinking.  Google is probably the closest to understanding what is actually happening.  The best any of us can do is observe.

 Source documents for all U.S. Federal information security:

OMB A-130 – Management of Federal Information Resources

FISMA – Federal Information Security Management Act of 2002

Federal Information Security Management Act of 2002 (FISMA, 44 U.S.C. § 3541) enacted as Title III of the E-Government Act of 2002 (Public Law 107-347)

Required for all government agencies  to develop, document, and implement an agency-wide information security program to provide information security for the information and systems that support the operations and assets of the agency Applies to contractors and other sources.

The federal government has created various acts/laws to implement to changes to the C&A process to a more risk management approach and emphasize a risk-based policy for cost-effective security. These acts include (but are not limited to):

  •  Federal Information Security Management Act of 2002 (amended as of 2013 April)
  • The Paperwork Reduction Act of 1995
  • The Information Technology Management Reform Act of 1996 (Clinger-Cohen Act) supported by Office of Management and Budget (OMB) through Circular A-130, Appendix III, Security of Federal Automated Information Resources


SRR Findings to IA Controls

From Reader:

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.

DIACAP Essentials + IA Control Validation Training (part 4): DIACAP/AFCAP Day3

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.

Day 3:

DIACAP Structure

Terminology Review

Assemble DIACAP Team

Registered System/System Information Profile

Assign IA Controls

Initiate DIACAP Implementation Plan

DIACAP Essentials + IA Control Validation Training (part 2): DIACAP/AFCAP Day1

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.

MS in Information Assurance or BS in Computer Science

I feel compelled to contribute something to humanity.

As a 15 year old street preacher, I was trying to help elevate humanity. When I look back at that kid now, I see the capacity for so much more but a lack of guidance that made my worldview grow wild. As a 20 year old airman, my world view was shaped and molded by discipline and the harsh, unrelenting realities of war and poverty.

The inescapable gravity of a child dying of an incurable disease in Africa is what prevents me from believing that this post-modern world can fit into a literal translation of ANY religious text. I don’t want to get into theology or philosophy too much on this blog, but I think it is relevant to this post.

Here I am now in my 30’s looking back at my life and at humanity as a whole and feeling (knowing) we can do so much better. I want to some how prove it to myself and humanity, but I’m a mere cubicle cog. What can I do? I’ve decided to go back to school, but I don’t want to knock out a 1 1/2 long MS Information Assurance degree. I want to get into science & math because they seem to be the two systems of study most like to limit human suffering and give us answers about who and what life it.

I don’t want (or really need) another industry type degree. If I go for a computer science or computer engineering, it won’t be for more money, or corporate movement to a better cubicle, it will be to have the privilege of understanding and perhaps even to create something that will help us evolve to our greatest potential and limit (if not end) human suffering.

I still want to dabble in security. I’m simply expanding the reach of my capacity to contribute to our movement upward.

Certification & Accreditation Change

Standard-issue security
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.”

Security, Interoperability, Supportability, Sustainability and Usability (SISSU)


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.

Approved IA Products

IA Control – DCAS-1, Acquisition Standards Security Design

This does not apply to EVERY type 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.

(edited: 29 August 2011. Fixed some text. Clarified some issues.)

DIACAP Activity #2 Implement and Validate Assigned IA Controls

**28 Sept 2011– DIACAP is being changed to the DoD Risk Management Framework. 8510.01 is being changed to reflect the NIST SP 800-37, with security controls matching that of the NIST SP 800-53. This information is being released on the DIACAP Knowledge Service**

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:

For Unix/Linux Systems:

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

STIGS and Security Guides

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.


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.

1 2