FISMA Report Card

I know that I am late on this one, but I have been busy. Just for a brief moment let's consider the point of these report cards and from where they come.

My personal feeling is that the report card means nothing and says even less. They apply an arbitrary metric to an ambiguous reporting mechanism. Any agency could have the best, most secure systems. If they don't report on it correctly, they can still fail. This also means that if the people performing the reporting are not trained correctly they can fail. Lastly, those who know how to report can pass without necessarily having secure systems.

Someone told me recently that the intent of this is to: a) make Congress feel good about doing something productive and b) inspire agency competition for success.

Sorry I am so negative on this, but again there is an "end of project requirements mismatch discovery". OMB, NIST and others recognize that good information systems security comes from well written policy and superior risk management. When others will tell try to sell IDPS, firewalls and log management platforms as solutions to your FISMA problems.

This report card reinforces an over simplified view of how easy/hard it is to secure an enterprise.

A New Draft of the Same Thing with Thoughts on Outsourcing

The 800-123 Guide to General Server Security came out this week, and really who needed this. I am sure this would have been helpful in 1995, when people had just started putting servers on the Internet. But who is seriously going to sit down with this and say "I hadn't thought of that!"

What I think we need now in the age of government *sourcing is some NIST guidance around Cloud, Managed and Virtualized systems.

My personal belief is that vendors are trying to get management/operation of government systems out of the government's hands so that there isn't as much bureaucracy.

Here is the thing, it is still the government's data. The system still must be certified.

To the Honorable Karen Evans: Please issue a memo stating unequivocally that: outsourced, managed, clouded virtualized, SaaS, shared whatevers need controls implemented to the same level that they would be if the government had built it themselves.

Quoteth the FISMA 3544(a)(1):

"(A) providing information security protections commensurate with the risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of—
"(i) information collected or maintained by or on behalf of the agency; and
"(ii) information systems used or operated by an agency or by a contractor of an agency or other organization on behalf of an agency;

So for those of you out there who keep saying "Chris, it isn't in the agency's physical boundary". Stop it. You know who you are.

More on this later (I keep saying this, but will it ever happen?).

800-39

I really don't have anything I want to address today, just a note to let you know I am alive. I have been mucho grande busy on a project for work and I am helping to redefine the process at work under my "Improve Your Process" mantra.

I will say this, I had committed to posting my review/comments of the 800-39. The reason why I am not is that I don't really have any. I don't really see the purpose of the document. It is high level, and only really says: do what the 800-37 tells you and conduct 800-30 style assessments in detail and often. So if you are brand new and require an overview, perhaps this will help. Sorry I couldn't be more help.

There is supposed to be a new 800-30 on the horizon that should match better to the 800-39. We'll see.

Update: I looked at the Second Public Draft of 800-39 with much the same feelings.

Happy New Year!

Among the things that I am working on, is this:

Improve your Process

This is any process. Getting out of bed, Multi-million dollar system migrations, Service Deliveries, whatever. So that's it. Do you need help - yes.

I can't say that it is the answer but a start would be to read The Goal. If you are reading this, then you are probably subject to Project Management and as such will want to read Critical Chain. To get a primer on Critical Chain, I would recommend that you listen to this episode of this podcast. It will help give a little more sense to the book.

Certification, FISMA, 800-series guidance. It is all process. Gassing up your car - process. We live our lives in processes. So just think of how much better it would be if our processes improved.

I spent 2 years in a process engineering group, for the most part I can't say that we did a whole lot. But I will say that we tried. New tools, the same bad process. Thus - the same failures. When I mentioned this to the director, I got the ole' "this company doesn't want to change" line. More to the point "these people don't want to change". So perhaps if you are in a position of authority, you should use it. If not, then it is time to become the squeaky wheel.

Obviously, the authority figures should recognize that they should not fear change because it will generally lead to better things. If properly communicated, I am sure anything can sound awesome. Anyone not willing to adapt to small changes in the way they conduct themselves, is not necessarily an asset to your group.

The squeaky wheels will have a more difficult time. The approach that I currently employing, is a grassroots effort of our group to implement some process improvements. Writing code, lunch and learns, random bitching, sample process improvements, etc. 18 wheels of squeak? That would be loud.

I am not much on preaching inspiration, but I think process improvement is important. Besides your the one who has read this far.

So, for 2008 Improve Your Process and Happy New Year!

PS - Seth Godin has some good ideas too, not directly related to Process Improvement. But inspiration for this post nonetheless.

Apologies and a new rant

I apologize for not keeping up with the blog.

I wish I had more time, apparently I thought I was going to manufacture some in the other room. I have been hard at work on a certification consulting task, a certification task, a personal web development project and general house administrivia (oh, and the holidays).

Since my last post, the 800-53A Final Public Draft is out. I think it is somewhat helpful, I am getting ready to use it on a project that is "bleeding edge" as they call it.

I suppose my concern revolves around using this public draft on 800-53 rev 0. That is not a typo, we certified something on rev 0 of the 800-53 and now we are going to be using 53A test cases. There will be gaps, there will be problems. I hope that we can plug them quickly.

What I hope to convey here is that the 53A contains test cases. They are not test steps. You will still need to turn these cases in to a meaningful process to test the control.

Case in point, AC-6 Least Privilege. Here is the control text:

Control: The information system enforces the most restrictive set of rights/privileges or accesses needed by users (or processes acting on behalf of users) for the performance of specified tasks.

Supplemental Guidance: The organization employs the concept of least privilege for specific duties and information systems (including specific ports, protocols, and services) in accordance with risk assessments as necessary to adequately mitigate risk to organizational operations, organizational assets, and individuals.

Here is the 800-53A Objective and Method:

ASSESSMENT OBJECTIVE:
Determine if: (i) the organization assigns the most restrictive set of rights/privileges or accesses needed by users for the performance of specified tasks; and

(ii) the information system enforces the most restrictive set of rights/privileges or accesses needed by users.

POTENTIAL ASSESSMENT METHODS AND OBJECTS:

Examine: [SELECT FROM: Access control policy; procedures addressing least privilege; list of assigned access authorizations (user privileges); information system configuration settings and associated documentation; information system audit records; other relevant documents or records]. (M) (H)

Interview: [SELECT FROM: Organizational personnel with responsibilities for defining least privileges necessary to accomplish specified tasks]. (H)

So we aren't suppose to look at the settings on the box? The answer is Maybe.

The whole gist of the NIST Special Pubs is that they are tailorable. If you, the assessor, you the security operations team or you in the back, the IG auditor, feel it necessary to add a test case with extra test steps. Then you must do that. I will be submitting comments on the 53A, especially because I don't feel on this one (in particular) that they have addressed the control. Look at the second objective in the example above.

I don't an Accreditation Authority that would say, "Nah, we believe that the system doesn't have to enforce least privilege. Our documentation and interview results should be fine. Don't check it."

If you are from NIST, please take no offense here. I want to help, explain or educate as best I can. I know it is hard covering all these bases and this format is much improved over 1st and 2nd public drafts.

This time I promise to post the comments I send on the 53A to NIST. Since I am actually going to do it this time.

Lastly, you will notice that there is something called an 800-53 Rev 2. My understanding is that the changes to it will mainly be affecting Federal Industrial Control Systems. I haven't done a compare yet. I have bigger fish to fry.