Management, compliance & auditing

Goodbye DIACAP, Hello DIARMF

November 17, 2011 by Len Marzigliano

When C&A becomes A&A, will you be ready?

Every few months, an elite group of DoD security experts, IT managers, and senior leadership gather to chart the future course for how Information Assurance will be conducted within the Defense Department. Very soon, this group will introduce sweeping changes to the Certification and Accreditation process, to the extent that personnel roles, job titles, and even the moniker C&A itself will change, evolving into new nomenclature and a new era for the Information Assurance community of practice within the DoD. After implementation, the use of DIACAP Certification and Accreditation processes will cease and DIARMF Assessment and Authorization will become the ‘new normal’ for information technology professionals and risk managers throughout the Defense Department.

The changes are an evolution of existing practices, but also a profound step forward that advances the practice of Information Assurance at DoD and reflects the growing importance of IA within the federal government. The shift also hails the emergence of cyber defense as an influential driver of Information Assurance policies and procedures government wide. Translation: IA is no longer just about checking off boxes for FISMA compliance. The increased threat landscape and looming budget scarcities demand a mature, efficient, and effective process which, when implemented correctly, DIARMF can deliver. The secret to success lies in being prepared for its imminent arrival and rapid deployment, and in sharpening the holistic approach of designing and building systems with IA baked in and not bolted on.

Defense Information Assurance Risk Management Framework (DIARMF)


The six major steps of Risk Management Framework aligned with the five phases of a System Development Lifecycle (SDLC)

DIARMF represents DoD adoption of the NIST Risk Management Framework process, using security controls currently in practice at civilian federal agencies. The DoD implementation of RMF puts a different spin on the process however, so those familiar with civilian agency IA controls and practices will still need to adjust when undertaking a military grade Information Assurance endeavor.

The most profound change aesthetically is the process and role nomenclature. What has commonly been known for years as Certification and Accreditation (C&A) under DIACAP (and its predecessor DITSCAP) will now be called Assessment and Authorization (A&A), to better reflect alignment with corresponding steps in the Risk Management Framework process.

Comparison of DIACAP and DIARMF processes, with policy references


At a high level, the activities in a DIARMF A&A are the similar to those of a DIACAP C&A, with Assessment producing an endorsed checklist of compliance with selected security controls, and Authorization consisting of an acceptance (or rejection) of the residual risk outlined in the Assessment report. In detail however, there are specific activities and nuances that are unique to DIARMF, which represent the evolution and maturity of the Risk Management Framework process.


Sample DIARMF roles in a hierarchal view (estimated)


As for DIARMF roles, most changes will be designed to further convey alignment with RMF terminology, but an important new role that RMF adds to the mix is the Common Control Provider, which is part of how RMF addresses control inheritance. The CCP is someone who manages inherited controls for Authorized systems like enclave networks, server clusters, or virtualized computing environments. For example, if your system physically consists of just a few servers in rack space provided by a large DoD datacenter, then chances are resources like air/humidity controls and fire suppression are provided by the datacenter and are not part of your system, in which case those corresponding security controls will be marked up as ‘Inherited’ on your Assessment, pointing to the controls of the already Authorized datacenter. Inheritance is complicated affair however; some controls are inheritable and some are not, depending on the shakeout of control selection. Furthermore, an artifact requirement exists (in the form of a system specific Service Level Agreement) for the control inheritance to be considered valid during Assessment. Also, the possibility exists that the loss of Authorization on the host datacenter would cascade down to a loss of Authorization for the hosted system, creating an important dependency that all stakeholders in the system and its project/program should be aware of.

The most substantial difference between NIST RMF and DoD enhanced DIARMF lies in the area of security control selection. To address the diverse and specialized nature of DoD systems, DIARMF employs a significantly more complex formula for selection criteria. Where NIST RMF categorizes systems using a one-dimensional scale of High/Moderate/Low based on mission impact of the system, DIARMF starts with a matrix of High/Moderate/Low impact splayed against the Confidentiality/Integrity/Availability of the data, then applies overlays for specialized characteristics like medical, industrial control, or weapons systems. An overlay can add or even subtract controls from the selection, and can also modify the variables (password length, key size, etc.) within the control statement itself. This shakes out to easily over a hundred different possible control sets that can be attributed to systems. DoD intends to tame this to a small degree by filtering out some unlikely combinations and by issuing a control selection calculator tool, but the complexity of control selection will nonetheless be a memorable feature of the DIARMF process.

When contrasting DIARMF to its predecessor DIACAP, the obvious standout is the security controls themselves. DIACAP practitioners will find the NIST library more substantial in quantity, yet more granular and specific within the scope of each control. For example, where DIACAP might fit an entire password policy into one control, the NIST control set in DIARMF will have a primary control for the password policy enforcement and individual control enhancements for each element (length, complexity, history, etc.) of the policy. Required control enhancements will be determined in the control selection process, and the variables within them (like the number of characters in a password length requirement or the number of unique passwords to be saved and enforced via history) will be dynamic, varying according to the impact ratings and overlays applied during the control selection process. There is actually a sub-committee at DoD dedicated solely to determining these variables and the formulas that generate them. Technical folks will find the text of NIST control descriptions and validation procedures more clear and concise, since they were written by their technical peers and contain less of the FISMA influenced legal bent often attributed to the DIACAP controls. NIST intends to revise the SP 800-53 control library every 18 months, based on threat analysis, attack trends, and other input provided by the National Security Agency, the Defense Information Security Agency, various federal and commercial CERT teams, and the newly formed US Cyber Command at DoD.

Equally profound within DIARMF is the increased requirements for Continuous Monitoring activities. Each control (and control enhancement) will be attributed with a refresh rate (daily, weekly, monthly, yearly) and requisite updates on the status of each control will be packaged into a standardized XML format and uploaded into the CyberScope system where analysis, risk management, and correlation activities will be performed on the aggregate data. The XML format will be a variant of the SCAP protocol currently in use for the Federal Desktop Core Configuration (FDCC) standard, also pioneered by NIST. CyberScope is akin to a giant federal-wide SEIM system, where high-level incident management teams can quickly pull queries or drill down into system details to add analysis on system defenses and vulnerabilities to the available intelligence on an attack. CyberScope data will also be used to track trends, make risk management decisions, and determine where help is needed to improve security posture.

It’s easy to fall for the misconception that the first frame of data in Continuous Monitoring is identical to assessment, but this is a pitfall to avoid. For starters, Assessment artifacts are sent to the eMASS workflow management system, while Continuous Monitoring data is sent to the CyberScope aggregator. Assessment involves more attestation of the control with a primary focus on the goalpost of Authorization, whereas Continuous Monitoring is more akin to a raw feed of the data behind the control.

Being prepared for DIARMF is a process in itself: Risk managers and C&A practitioners can (and should) start early by reading the available policy documents now, and by reading the revised/reissued policy documents as they are released. Diligence should also be given to the local scene, as various services and major commands will be revising and re-issuing their own policies and procedures, which will contain valuable details as to how they expect the job to be done. Shortly after DIARMF is formally announced is when its implementation will begin, and folks should follow up with a training course designed to update their skills from DIACAP.

The shift within DoD from DIACAP C&A to DIARMF A&A is a profound change, and the rise of Continuous Monitoring will double the stakes in terms of cost and effort. Practitioners of the traditionally civilian agency NIST standards will be in high demand because of their knowledge of the SP 800-53 control set and SP 800-53A control validation procedures, whereas DIACAP practitioners are only an upgrade course away from being spooled up on the new controls and processes. It’s impossible to understate how all Information Assurance practitioners must be prepared for the profound and swift changes that lie ahead.


“The dogmas of the quiet past are inadequate to the stormy present. The occasion is piled high with difficulty, and we must rise with the occasion. As our case is new, so we must think anew and act anew.”

Abraham Lincoln, 1862


Posted: November 17, 2011
Len Marzigliano
View Profile

Len Marzigliano is an Information Assurance Manager with defense contractor BAM Technologies in Arlington, Virginia and a researcher for InfoSec Institute. With over 20 years experience as an IT contractor and consultant, Len has worked with hundreds of organizations and project teams in commercial, civilian federal, and defense environments worldwide. His certifications include (ISC)2 CISSP, NSA IAM/IEM, and EXIN ITIL. Len’s information security blog can be found at

19 responses to “Goodbye DIACAP, Hello DIARMF”

  1. Excellent write up. I haven’t been able to locate any official documents stating this yet, but I’ve heard it via word of mouth. I am much more familiar with the 800 series than I am with DIACAP, so this is actually good news to me.

  2. Len says:

    Thank you sir. This been brewing in various technical advisory groups and with senior leadership throughout DoD since NIST revised their IA controls in 2007. It’s picked up steam significantly this year however, and folks should expect issuance of the official policy rewrites ‘soon’. -=Len

  3. Toni Chefo says:

    It is better to be involved in the process, looking at the system as a whole rather than “just” compiling data. Data is just that, data. Data is good for identifying trends and forming conclusions, but those conclusions are useless if you’re blind to the bigger picture.

    Monitoring has it place, but there needs to be reactive and proactive procedures in place that combined with the compiled data, a system can look perfect and still be vulnerable. We are in an ever changing world, technology changes quicker than computers can keep up. There are always more threats than what meets the “eye” or in this case the data.

  4. OutSourceThis says:

    Great more government pinhead controls. I’m tired of government contractors in some think-tank justifying their existence by convincing the government that they need to change their controls to some over thought framework that in fact does not create more protection as much as it creates the illusion of protection. This of course leaves us federal subcontractors to somehow implement this crap that our federal handlers expect somehow their outdated defensive security models will protect their networks and data.
    How about less complicated frameworks and policies and better security, or how about we move into what the rest of the security world sees and use offensive security, instead of more layered defenses. I’ve got federal auditors who are more worried about how my SSP’s are written then how I secure my applications are or how my controls protect their data….Sorry to harp on your write up which is very good but the subject matter is a pain in my side with all the NIST 800-53 compliance.

    Most government paid nonprofit auditing/security companies (I won’t mention names) don’t live in the real world so these controls make perfect sense in their small little rooms. If the government wants better security they should hire companies with an interest in security our country not companies interested in staying the embedded choice to justify their salaries and jobs.
    Again sorry to vent I appreciate the write up letting us know what is coming next.

  5. Ken says:

    Thanks for the article. I must say that we need to be careful what we write especially without proper references. As a reader I expect to have a way (source) to assist in my critical analysis, especially when it involves such a profound shift in the IT/IS discipline. This proposed framework is an interesting concept and one that needs input from a larger audience, especially practitioners and scholars – this should be peers reviewed. Making a cultural change of this magnitude requires a robust level of community involvement along with detailed analysis of impact. So Thanks again for the “heads-up” but please cite your source to increase the validity of your article allowing the reader to evaluate the information.

    • HenryM says:

      I agree. Very interesting, with a lot of details, but if there are sources to cite, they should be cited, and if there aren’t, then that, too, should be explained.

  6. George Johnson says:

    Thanks for the write up. I didn’t catch a timeline for the rollout for the DIARMF to be implemented. Would you know of one? Also, we have been down this road before with the ICD 503 “stuff”. And also as well and as you have indicated in your article the release of this framework is just the beginning as every subordinate command seems duty bound to put their own form of branding on the framework (just muddies up the water) so we will have to wait on those regs to come out as well. I would like to be able to tell my dev team and our customer that we have a solid IA course of action and not be underminded by this new stuff every other year.

  7. David S. says:

    Unfortunately (because of the inevitability not their comments) I have to agree with OutSourceThis and RiffRaff. Security practitioners will be forced to spend more of their time producing reports or managing systems to provide them – taking time and effort away from the actual defense of their networks. DIACAP was intended to reduce the administrative burden of certifying networks and it failed because what started as a streamlined process turned into an unmanageable hydra of bureaucracy. DIACAP also worked on a three-year cycle. Now, with DIARMF you talking about an 18 month cycle where controls will need to be reviewed incessantly in order to ensure they meet ever-changing requirements. It’s tuff to hit a moving target and it doesn’t look as though DIARMF will reduce the bureaucracy either. The direct-hired IT workforce can’t keep up with requirements as it is. This will create an even greater dependence on contracted services and drive up the total cost of system management in already shrinking IT budgets.

    I know — “there you go with the negative vibes” — it’s just the way *I* see it.

  8. Stacey Demick says:

    Recently the DIACAP KS (Knowledge Service) opened up its doors to a wider audience of CAC holders to include DoD contractors. KS has pertinent information and checklists to streamline the administrative burden of mapping the 800-53r3 to the traditional 8500-2 controls.

  9. Steve L says:

    Someone mentioned that DIACAP was suppose to streamline and reduce the administrative overhead of C&A. The couple of places I have worked took DIACAP and twisted it into some mutant form of DITSCAP. Old habits are hard to break, especially in the government.

  10. Curtisgbjr says:

    This is a good article about the transition to the RMF. I don’t think the shift in processes
    from the validation point of view will change that much in reality. The mapping of NIST
    SP 800-53 to DoD 8500 IA has been done numerous times by a number of primary C&A
    providers since the first draft of SP 800-53 was published several years ago. The only real
    change that requiring monthly scan results for input to the CyberScope system is the shift
    to a nation collection system vice a DoD component system like VMS. In fact its likely
    that you will be required to submit the results to both systems for the foreseeable future
    since VMS will be the feed mechanism for eMass (for US Navy) during the “transition” from DIACAP
    to DIARMF.

  11. Chris Davis says:

    DIACAP to DIARMF has come up on a few email threads and I found this write up through a Google search for commentary on the transition. Thanks for your posting.

  12. M.Rieger says:

    Great article!

  13. Timothy Nelson says:

    Solid article Len!

  14. Tina says:

    Len, where can I get more info? What where your sources? I’m trying to do a paper on DIACAP transformation.

    Thank you!

  15. Terry Clapp says:

    What I haven’t seen documented anywhere is how DIARMF or NIST will handle those systems that do not have any continuous monitoring options. I know for example that CMS (Medicare) sends someone on site to do an annual assessment of IBM mainframes since there is not a continuous monitoring option for them.

    • Brooks says:

      Terry, you aren’t going to find specific guidance on how to handle those systems that do not support “continuous monitoring”. The nasty little secret that many haven’t recognized yet is that the new NIST framework is to genericize the approach to cyber security. If you want to chat more feel free to email me

  16. Lena S. says:

    As always, great read, Len! Food for thought, and learned a lot from this to take away, with a glimpse forward as applies to my environment, and in general.

Leave a Reply

Your email address will not be published.