If you haven’t heard, NIST has recently published Special Publication 800-128: Guide for Security Configuration Management of Information Systems. Local NoVA blogger Chris “@cyberhiker” Burton recently put out a detailed post with his thoughts on this newly release document. Based on Chris’s review, it looks like a step in the right direction … but then remember there are always many more steps to ascend … and sometimes the destination changes.

Take it away @cyberhiker!

#####

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.

#####

So what do you think? Why not head over to @cyberhikers‘s “My Take on 800-128 (Intentional Rhyming Attempt)” blog post and leave him some comment love!

If you’re getting a little tired of the debates surrounding the Cybersecurity issue, you’ll find the posts we selected for this week’s “Top NoVA Infosec Blog Posts” refreshing.

#3 – The Art of Persuasion: In his post “Recognizing False Arguments,” @electricfork outlines the familiar arguments that many of us hear when we try to convince our employers that a gaping vulnerability won’t just fix itself or go unnoticed by attackers. While employers tend to come up with all kinds of arguments—many of them ranging from slightly absurd to completely ridiculous—the reality is that we must be prepared to show our employers why vulnerabilities cannot remain unfixed. @electricfork does a great job of outlining basic responses to some of the most common arguments used against fixing vulnerabilities. You can check them out here.

#2 – What the Hex: For those of you who haven’t used a hex editor before, or are looking for a new one, you’re in luck. In their post “XVI32: Hex Editor of Champions,” @geminisecurity talks about hex editors (the XVI32 hex editor specifically), and why we should use them. Calling the hex editor “an essential tool for anyone in the computer security field,” @geminisecurity says that hex editors are especially good for looking at the nitty-gritty details of data. The XVI32 is no exception. Describing the XVI32 hex editor “a very robust, stable, and easy-to-use hex editor for Windows,” @geminisecurity says that some of its best features include a built-in scripting engine, bit manipulation capabilities, and numerous ways to interpret and display data. You can check out all the details here.

#1- Think Outside the Toolbox: The PaulDotCom post “Find Time to Put the Tools Away” opens with an interesting comparison of pen testing eerily resembling airport security. Both pen testers and TSA professionals are trained to look for very specific things, often overlooking other potential problems because they neglect to see the big picture. For example: Instead of looking for certain vulnerabilities like XSS, XSRF and SQLi, PaulDotCom encourages security professionals to look at how an application works instead of looking at the parts that make it work. He also gave one of the most profound pieces of advice that we’ve heard in awhile: “Trying to understand how something worked used to be the goal and definition of hacking.” And on that note, I hope that you’ll read the post yourself.

Don’t forget to follow me during the week @grecs to get more recommendations on the blog posts you should be reading.

o o o o o

Wanna hack your career?

For those of you who didn’t get to attend the OWASP – VA Local Chapter meetup last Thursday, February 12th, here’s a quick breakdown of what the meetup was about.

Presented by John Steven, “Moving Beyond Top [N] Lists” was an interesting commentary about why “Top Lists” don’t solve problems. If I could sum up Steven’s presentation in a nutshell, it would be that each problem—and each company or organization encountering problems—is different. Just because one “Top Ten” list cleared up Company A’s vulnerabilities, it doesn’t mean that same list will help clear up all of the vulnerabilities being experienced by Company B. 

Along those lines, Steven also focused on the disconnect between management and security professionals, presenting a list during slide 9 of his presentation that started with the line: “Executives don’t care about technical bugs.” Steven went on to emphasize later in his presentation that when executives finally get around to caring about the bugs that they had been ignoring for so long, they get so fixated on the bugs being the problem that they completely ignore flaws or vulnerabilities.

Dealing with unhelpful management aside, Steven asserted that the only way to really fix current or future problems is to “Know thy enemy & how they attack you” during slide 15 of his presentation. The rest of his presentation was spent talking about how to do just that: From considering misuse/abuse, or what to do with annotated attacks, Steven provided extraordinarily useful information that anyone who is currently in management, would like to go into management, or is forced to deal with management or executives on a regular basis should check out.

You can view Steven’s presentation slides on the OWASP site.

For more information on the OWASP – VA Local Chapter, see its description in our NoVA Meetups section. View our Calendar for a complete list of infosec events in and around the NoVA area.

###

Was this post helpful? If so, consider passing it along to a friend or becoming a subscriber of our site. Or, you can always do both—we won’t complain.