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.

800-39, 800-60 and VBScripts that may help you.

I am slowly making my way through the 800-39. I like it so far. I worry that because it hasn't specified a deliverable yet that it will get no notice or play. I hope that it does soon. I also await the arrival of the updated 800-30 since there are clear overlaps. What would probably be helpful for anyone reading is posting my comments and markups. I am not sure how NIST will respond to it.

I also saw a that there is a new 800-60. I can't even begin to contemplate when I will get to it. The last one was weak and I don't think anyone I knew even read it. I know this because when I asked them what information type their system was processing, I instantly received a blank stare. When I was engineering Federal systems, they didn't have an 800-60 or FIPS 199. So, we merrily wrote our SSP, conducted Risk Assessment and ran the ST&E's. I get the feeling here that because they bothered to update the documents, that they will probably get a little more play.

It is my opinion, that if more system owners sat down and determined their information types, then boundary identification would be easier. I won't go into it, but please stay tuned for a post on system boundaries.

Lastly, I wrote a couple VBScripts that help me with my Nessus scanning. Since Nessus is still free (7 day lag on plugins) and generally useful I provide my little scripts for you to review and abuse. The script will run against one or multiple result XMLs, and provide output in the form of MS-Excel. They are located at http://www.redeyetek.com/Tools/. One for the results from a Linux scanner and one for Windows client.

Things to look forward to: Another VBScript that make XMLs from the DISA SRRs into MS-Excel. And a post on System Boundaries.

The GAO Report

I have read the GAO report (pdf). Really my only comment is “DUH!”. Tell us something we don’t know. But it may be shocking to Congress.

The report basically recaps all the deficiencies that I already knew, and some that I didn’t know. Like the IRS, they apparently have huge deficiencies, despite the SCSEM that I ran up against a number of years ago. Which was a decent policy, their issue (as with most) is implementation.

So, if you are having issues getting your policy in line. I heard the SecurityExpressions can do an “Audit on Network Discovery”, or something like that. Unless you get all OKs on your policy check when you attach your laptop to the network, you don’t get network access. Maybe it was just a beta thing that the Sales guy said was on the horizon, but it would be cool if you could do it.

Imagine that only certain MAC Address are allowed to connect and those MACs must be compliant with the system policy!

The report also calls out Inventory and Configuration management, which falls in with what I have already said above. If you know what machines are allowed to connect to the system and the configuration is enforced or the machine is denied access – then the ISSM will know exactly what is going on.

GAO also says that the Inspector Generals are not enforcing a common testing criterion. Well. What do they want? The 800-53a is in third public draft, and given the size of some of these agencies, and the money given to the IG for independent review – how is an IG to get through it all.

It is worrisome for me that the GAO put this report together the way they did. Not that it should really changed anything. I would worry that Congress would put their considerably sized nose in the middle of NIST’s and OMB’s business.

Congress and GAO shouldn’t be expecting miracles and they can’t compare FISMA to SOX, GLBA and HIPAA. Those are laws for the public and there are real penalties for non-compliance. I have yet to see a CIO go down for not keeping a major system inventory or for accepting a risk that could have been mitigated.

Call me an optimist, but every time a report comes out or there is a new public draft. I think “Oh goody, now we are getting somewhere”. Perhaps the 53A will help somewhat, maybe after the SCAP conference in September some new tools will come out.

But this is not that.