History of C&A

nist risk management framework 800-37

February 1, 2014 by Bruce Brown Leave a Comment

NIST risk management framework 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems (revision 1) marked a change from the old NIST 800-37 that was based on Certification & Accreditation. The adjustment stems from FISMA 2002 and includes the following changes:

Revised process emphasizes
Building information security capabilities into federal information systems through the application of state-of-the-practice management, operational, and technical security controls
Maintaining awareness of the security state of information systems on an ongoing basis though enhanced monitoring processes
Providing essential information to senior leaders to facilitate decisions regarding the acceptance of risk to organizational operations and assets, individuals, other organizations, and the Nation arising from the operation and use of information systems

The DoD has recently adopted the NIST risk management framework 800-37 steps (called the DIARMF process). There are 6 step: Categorize, Select, Implement, Assess, Authorize and Continuous Monitor.

: risk management framework steps

nist risk management framework 800-37 – Step 1. Categorize

The first risk management framework step is categorization. This step consists of classifying the importance of the information system. This is done by the system owner with FIPS 199 and NIST 800-60.

Categorization is based on how much negative impact the organization will receive if the information system lost is confidentiality, integrity or availability.

nist risk management framework 800-37 – Step 2. Select

With FIPS 200 and NIST SP 800-53, the organization responsible for the systems security will select the security controls required to limit the risk to their organization. The selection of the controls is based on the categorization of your system. A system security plan is created as a guide to what will be installed and/or configured on the system.

nist risk management framework 800-37 – Step 3. Implement

Using the System Security Plan, the organization responsible for the categorized system can begin risk management framework step 3. This step is implementation which is installation and configuration of security patches, hotfixes and security devices where necessary. Guidance for actual implantation has to come from technical manuals, system administrators, system engineers and others technically competent enough to do the work.

nist risk management framework 800-37 – Step 4. Assess

The organization has to make sure that the security controls are implemented properly. This is done in risk management step 4, assess. Using NIST SP 800-53A, Guide for Assessing the Security Controls in Federal Information Systems and Organizations is used to determine which controls have been fully implemented to limit the risks to the organization.

nist risk management framework 800-37 – Step 5. Authorize

Even after implementation and assessment of the security controls that limits the over all risk to the organization, there is some remaining (residual) risk. The organization must have someone who has enough authority of over the system to accept the residual risk. This person is known as the Authorizing Official.

In risk management framework step 5, an Authorizing Official makes a formal, written acceptance of the risks. The AO makes a decision on whether or not to accept the risk based on the authorization package. The authorization package consists of the system security plan, plan of action and milestone, security/risk assessment report and any other supporting documents.

nist risk management framework 800-37 – Step 6. Continuous Monitoring

After acceptance of risk by the organization, they must develop a program that monitors the ongoing changes to the systems security posture. They take a proactive approach to watching for advanced persistent threats, configuration changes and new vulnerabilities. Risk management framework step 6 handles all of this.

More on DIARMF – Continuous Monitoring

ditscap supersedes diacap

January 19, 2014 by Bruce Brown 1 Comment

DITSCAP Supersedes DIACAP?

No. FALSE!! In fact DIACAP replaced (superseded) by the DIARMF process. DIACAP replaced DITSCAP 7 years ago. Now DIACAP is being replaced.

So it was the other way around (7 years ago). DIACAP superseded DITSCAP. DIACAP was released about November 2007 and at that time was replaced by DIACAP by most of the Department of Defense.

As a system security engineering contractor, I can tell you that MANY organizations clung to DITSCAP for many years after 2007. Some local government units even made it policy to NOT go to DIACAP. I think this was out of ignorance or great resistance to change. The government attracts very conservative, traditionalist that are highly resistant to change. If you are into doing things faster and smarter and keeping up with the break neck speed of information technology, you will have a frustrating time in the government… ESPECIALLY, if you care.

Since DIACAP is now being replaced (circa 2014), its amazing to me that people still even know what DIACAP is!! What is more amazing to me is people insisting that, “ditscap supersedes diacap”. That is so wrong that it makes me speechless. Its like someone insisting that the sun revolved around the Earth. I cannot use logic against religious belief. In some cases, its really just that they don’t know any better and are new to C&A/RMF and so its just a matter of giving a quick look at the history of C&A.

When I meet DITSCAP fundamentalist, I don’t waste ANYTIME debating regulations. I mean, its written in black and white. If they are too lazy to pay attentions to 10 years of C&A evolution, there is nothing to talk about. I have no intention of changing their beliefs. I just talk directly to the system owner, if it is within my responsibility and authority to do so.

Brief History of C&A

January 17, 2014 by Bruce Brown Leave a Comment

Over the years I have noticed that not many people in IT know what Certification & Accreditation is. IT professionals specializing in some aspect of system, network or software security usually know of it by one of its many names. Some call it as assessments. A generic name would be a security check, but the new name the government will use will be Assessment & Authorization. Those of use who have had a chance to do it call it a pain in the ass!

I cannot complain too much about it because the work has paid my bills for years. I am doing mostly technical work right now, but I still keep a close eye on C&A.

For those of you who want to know more, here is a brief history of C&A:

In 1985 by the National Computer Security Center (NCSC) (now known as the National Security Agency) published the Trusted Computer Systems Evaluation Criteria (TCSEC), the “Orange Book.” It was apart of a series of computer security standards known as the Rainbow series. These books covered everything from cryptography, to authenticate to verification systems.

Information Technology Security Evaluation and Certification (ITSEC) in 1991, came later from Europe. These standards evolved into international standards known today as common criteria.

The Orange Book became DoDD 5200.28-STD, DoD Directive 5200.28, “Security Requirements for Automated Information Systems (AISs),” March 21, 1988, which is the basis of DoD 5200.40, DoD Information Technology Security Certification and Accreditation Process (DITSCAP). In 2002, DITSCAP was replaced with DoDD 8500.1. 8500 begat 8510, DIACAP … and Boaz begat Abraham and Abraham begat Choazz.. (ok.. a little KJV humor there).

But seriously, Department of Defense Instruction (DODI) 8510.01, DoD IA C&A Process, (DIACAP) comes from the Orange Book in the old Rainbow Series.

Now it has evolved again to become the Defense Information Assurance Risk Management Framework.