Posts RSS
Subscribe via Email
Some Comments on SP 800-39
Posted April 6th, 2011 by rybolov
You should have seen Special Publication 800-39 (PDF file, also check out more info on Fismapedia.org) out by now. Dan Philpott and I just taught a class on understanding the document and how it affects security managers out them doing their job on a daily basis. While the information is still fresh in my head, I thought I would jot down some notes that might help everybody else.
The Good:
NIST is doing some good stuff here trying to get IT Security and Information Assurance out of the “It’s the CISO’s problem, I have effectively outsourced any responsibility through the org chart” and into more of what DoD calls “mission assurance”. IE, how do we go from point-in-time vulnerabilities (ie, things that can be scored with CVSS or tested through Security Test and Evaluation) to briefing executives on what the risk is to their organization (Department, Agency, or even business) coming from IT security problems. It lays out an organization-wide risk management process and a framework (layer cakes within layer cakes) to share information up and down the organizational stack. This is very good, and getting the mission/business/data/program owners to recognize their responsibilities is an awesome thing.
The Bad:
SP 800-39 is good in philosophy and a general theme of taking ownership of risk by the non-IT “business owners”, when it comes to specifics, it raises more questions than it answers. For instance, it defines a function known as the Risk Executive. As practiced today by people who “get stuff done”, the Risk Executive is like a board of the Business Unit owners (possibly as the Authorizing Officials), the CISO, and maybe a Chief Risk Officer or other senior executives. But without the context and asking around to find out what people are doing to get executive buy-in, the Risk Executive seems fairly non-sequitor. There are other things like that, but I think the best summary is “Wow, this is great, now how do I take this guidance and execute a plan based on it?”
The Ugly:
I have a pretty simple yardstick for evaluating any kind of standard or guideline: will this be something that my auditor will understand and will it help them help me? With 800-39, I think that it is written abstractly and that most auditor-folk would have a hard time translating that into something that they could audit for. This is both a blessing and a curse, and the huge recommendation that I have is that you brief your auditor beforehand on what 800-39 means to them and how you’re going to incorporate the guidance.
Similar Posts:
Posted in FISMA, NIST, Risk Management, What Works | 
5 Comments »
Tags: 800-37 • 800-39 • accreditation • assurance • auditor • C&A • certification • comments • compliance • datacentric • fisma • government • infosec • management • NIST • risk • scalability • security
April 6th, 2011 at 3:24 pm
I think it is a wonderful academic exercise describing a world in which I do not live.
This is a top down driven program, and I can’t see how it will work unless the top (Tier 1) actively participates. If the top of your organization participates, then your security program will succeed, even whether it is based on RMF or on examining the entrails of turtles.
This document leaves Tier 2 and Tier 3 standing on the tarmac waiting for the Tier 1 plane to land. It defines risk in ways that are not harmonious with other government efforts (e.g CAESARS, cyberscope, etc.) Tier 2/3 people can pretty much guarantee that whatever they try to do in the short term is wrong.
As a consequence, I predict more legislation from congress to define cybersecurity. And I predict the value of Rybolov’s diagram showing the shear between technical views of security and compliance/regulatory views of security will become ever more valuable.
My advice? go get a law degree and seek out a position as a lobbyist or congressional staffer. From here out out the domain of cybersecurity has nothing to do with bits and bytes and everything to do with committee assignments and election returns.
April 8th, 2011 at 2:34 pm
Hi Mark, I don’t think you’re the target audience for 800-39. =)
April 11th, 2011 at 12:13 pm
If so it is news to myself, my boss and my colleagues for the past three years. I might have to give back much of the salary I’ve earned supervising risk managers.
Seriously 800-39 is a fish in the moonlight. From a distance it looks shiny and beautiful, but as you grow closer you notice the smell.
April 13th, 2011 at 1:35 pm
Wow, interesting comments — ” a fish in the moonlight”. Good one. I’d like to understand the reason for these criticisms and the general cynicism.
Sure it’s no uncommon for NIST to write guidance with an academic point of view. After all, they are scientists. In this case, however, one of the principal contributors is a non-NIST, government staffer who has been instrumental in leading the charge for “Continuous Monitoring”. Unlike Mr Wallace, when I read NIST 800-39, I see significant synergies with the federal government’s way ahead, particularly the concept of continuous monitoring. Perhaps my point of view is biased by perception of this one author’s contributions…?
As for the original post, if “The Bad” and “The Ugly” are limited to the fuzziness of the Risk Executive function and the concern about what an auditor is going to do, then NIST 800-39 is in good standing. NIST is appropriately vague in the Risk Executive function, as they do not attempt to dictate a particular organizational structure. As it relates to auditors, let them focus on the controls, specifically NIST 800-53 and 53A. One could interpret NIST 800-39 as simply providing more assistance on how to implement the Security Program Management controls, such as PM-9 and PM-10. These PM controls will likely evolve as NIST 800-39 receives more comments and matures over time.
I would definitely like to see more commentary on this. I actually do share some of the cynicism, but it is mostly related to a lack of accountability and clarity around who owns which machines, OSes, Apps, etc. This simple problem becomes extremely difficult in the very large, complex organizational structures that exist in FedGov. Perhaps, I just stumbled onto the big issue with 800-39, its simple 3-tier structure may be impossible to implement in Agency X, where there are really 10 layers of management which is complicated by matrix-allocated personnel…?
Regards,
David Wilson (a) telos.com and twitter:DJWILS285
April 14th, 2011 at 9:20 am
(I believe fish in the moonlight is an oriental proverb).
Under the old regime, I could give good advice and counsel to the stakeholders (system owner, security manager, etc.) about what to do.
In the new regime, I’m trapped into “Well, you might want to do this, but the risk executive hasn’t said anything so pretty much everything you do is going to be the wrong investment. So your best strategy is to be a bureaucrat, do nothing and write frequent memos requesting guidance. If you don’t secure the system and it is penetrated by a 12 year old from Detroit, you’re safe. But if you invest in strategy X and the risk executive decides to back Y, then you’ve wasted government money.
And of course the risk executive (if they ever name one) will do nothing because there are always at least three bills under consideration in congress that are mutually exclusive, technically unimplementable and politically motivated.
So if you want to be successful, forget packets. Study law and lobbyists.
800-39 speeds us further and further from accountability. It contains many good words and vague definitions that anyone can use to demonstrate that they fully supported whatever happened. It doesn’t contain a strategy.
And OMB/Cyberscope is demanding continuous measurement which is fundamentally at odds with 800-39. The two definitions of risk are incompatible. Failure to meet OMB will cut my budget. Failure to meet 800-39 has no consequence.
Study law.