My Take on 800-128 (Intentional Rhyming Attempt)

I did not get a chance to read 800-128 during the draft phase, mainly because I was too busy. But also because I wasn't all that worried. I did however have one of the analyst I work with read it and he had some positive things to say. So if this comes across as not news to you or something akin to a 12 year old girl saying "Duh!", then please excuse me for just now catching up.

Pros (in no particular order):

1. A consolidated place for information on Configuration Management.

2. Control References - in section 2.3 there is a description of the activity to be performed and THEN the control reference.

3. The Appendices.

4. Very Nearly The Holy Grail of Federal IT Systems Compliance (keep reading).

Cons (also in no particular order):

1. The introduction of Security-Focused Configuration Management (SecCM).

2. Tries to make it an organizational problem with limited dealings when it pertains to system.

3. Limited to no mention of outsourced systems OR how to handle "cloud" environments.

This document contains how configuration management should be done in and around the Federal government. This has been needed for a long time, especially since many places do configuration management incorrectly and/or half-assed. Some of which rely on the 800-53 controls as their implementation guide. But the document does mention SDLC in the document with pointers to things like 800-64.

If you do not know what you are doing, or simply want some place to start, then 800-128 is for you. If you have a decent program or want some tips on how to improve it; I don't know that you'll find any of the answers that you seek in 800-128. It will not fix personality problems with co-workers, but there are some explicit recommendations that you could use as a bat to beat them with.

The key point that NIST is driving here is the SecCM concept. SP 800-128 is not "transforming" configuration management but (as the name implies) wants everything relating to configuration management to be security centric. This may conflict with those who believe that configuration management is all about making it easy for IT administrators and developers. Especially if the security and operations staff don't get along with each other. I think it would be best to continue selling it as a performance and efficiency enhancement, while reaping the rewards of better documentation and system configuration monitoring.

What you will find is some decent appendices that have templates for a Configuration Management Plan and a Security Impact Analysis. Two things that desperately need consistency between departments and agencies. Some people may find the work-flows in Appendix G somewhat helpful for visual learners. However, Appendix F is the least helpful in that it regurgitates everything we know about securing a system and points you to a number of the other 800-series documents.

You may remember from above that I mentioned that you may find the Holy Grail of Federal IT Systems Compliance in this document. No it is not, "The Definitive Guide on How to Establish an Authorization Boundary". Attachment 1 (part of the SIA template - not even in the Table of Contents) at the very end of 800-128 has 10 questions that ask whomever is filling out the SIA template to identify the significance of a change. I believe that it is a worksheet that concisely identifies whether a change is significant enough to require a re-authorization event. Which is kind of a big deal. This is in fact my version of trumpeting it from the mountain tops. I think that it will need to be customized to the individual agency or department that is using it. Also, PLEASE let me know if you have seen this gem before and I have just missed it.

Now for the bad news. The document is almost fanatical about the need for something to come from the organization (Section 3.1.1) as it should be. The problem is that with service purchases, outsourced systems and clouded systems, there really isn't a super way to have software run on those components for it to report back to the mother ship. This is the part where you say: "Chris, I can just upload my SCAP results at the end of the month". OK, fine you got me. Have your junior squirrels or security monitoring staff upload some properly formatted XML results every month or setup a scheduled job to do it for you. My experience is that sending that level of granularity to an agency or department leads to information overload OR having to track and approve many, many waivers and exceptions. That isn't to say that you shouldn't try. I would say that there may be pieces of what 800-128 puts on the organization that needs to be pushed to the system or that things that are the system's responsibility need to be addressed by the organization.

I think that it is also a little naive to expect that the SIA is going to be conducted in the manner described in Section 3.3.3 given the release cycle of some systems (especially those that are behind or late).

Lastly, it wouldn't be a NIST document if there weren't an allusion to the use of software tools to improve efficiency. This one is no exception. SCAP would be nothing without scanning and assessing tools, but tools are not going to fix the problem. Without a clearly defined policy -> procedure -> process -> document trail, then you are trying to row upstream on a quickly moving river. On larger systems, tools definitely need to be used. That doesn't mean that you need to stand up something separate from what operations is doing to manage the systems.

As always, 800-series documents are recommendations not requirements. Develop your processes in a way that works for where you are and build in tools and technology around it. But the 800-128 is very good at helping with the bulk of the work that Continuous Monitoring is trying to accomplish.