Missing the Point ... Again.

There has been a lot of who-ha (technical term) going around on the changes to Information Security in the Federal government. As the title suggests, there are many, many pundits and "experts" who proclaimed FISMA as a failure and needs an overhaul. It is my opinion that very little will actually change. Why you ask?

Institutional Momentum.

Like most things in the government, the original idea came from DoD and the Intel community. In this way, Certification and Accreditation could be a point in time event because they were running mainframes with hard wired terminals. So things did not change all that often. Systems evolved, web applications were developed, cloud computing, buzz word du jour, blah blah and suddenly the process is broken.

Did you know that certification is only mentioned once in FISMA? And not even the certification that we think of, it concerns a certification authority for digital signatures. Congress did not force the Certification and Accreditation process onto the Executive. If we jump into our way-back machine you may recall a post where I said that FISMA is about risk management. Continuous monitoring and vulnerability management were part of this vernacular from the start. FISMA was perverted into a checklist / table top exercise to keep costs and schedule under control, which is totally permissible if you accept the risk. Some of the feds simply were not ready to implement the NIST recommendations. Some still are not.

You may also know that a few weeks back, SP 800-37 Rev 1 went final. It seems that it has taken just over seven years, but the government produced meaningful recommendations to create a process to manage risk. With this document and the upcoming SP 800-39, we finally move in the direction of strategic risk management. While I have only taken a cursory look at the bills on the Hill, my understanding that there is little in the way of increasing the government’s ability to respond to incidents, perform practical contingency and business continuity exercises or enforce more extensive testing methodologies. I believe this has to do with vendor influences, but I could be completely wrong in my assumptions.

FISMA has done exactly what it was intended to do. Those who didn't/don't/can't understand security, vilified it from the start. Which I felt was an attempt at a self fulfilling prophecy. Lest we forget where we were in 2002. Very little was done beyond a firewall on the perimeter and some A/V on the desktops. Because of FISMA and the thousands (perhaps millions) of findings written, many more technologies have been deployed such as web application testing and intrusion detection. We all understand that we can and should do more, but that is all security programs. This one just happens to be open to regular public criticism. Outside critics should consider the 800 series documents for what they are, guidance for the creation of a solid security program and not as simply a compliance effort.

It would have been better if the new legislation simply said "Do what we already told you to do, but ‘this time with four part harmony and feeling’". Ending with funding for agency staff education and time off to go learn what information system risk management really is.

The Amtrak Post

Hello from a stopped Amtrak train near Aberdeen, MD.

I just wanted to spend a few minutes to let you know that the SCAP Conference was almost a total bust. This would be mainly due to no new information. At least last year, I left the conference with the hope that things would change through a new 800-37 or the final release of the 800-53A.

This year was mainly about scanning. For someone who has done more than a couple scans, it was painful. Dr. Ron put on his usual show about the future and how great things will be eventually. Other speakers lacked public speaking ability which took away from their content. Don't even get me started on the grammar errors in the presentations or the blatant "I am great. Look at what I can do, but you f%#!ers are screwed".

If you were a vendor, then this was probably a dream for you. Captive audience with a narrow focus. If you could spell SCAP, then you were set. But I am not here to ding the vendors, that's just how capitalism works. There were a few good sessions on how SCAP works, which some of those vendors found to be news. While empowering the attendants to understand what to look for when choosing a product.

CSAM is now a web based product which I somehow missed. I didn't get to see it but my new friend Shawn likes it.

They seem to be very proud of themselves for getting the IC and DoD on board with some of the 800 series. I suppose that is good, but I got tired of hearing about it after the 16th time.

I would have preferred to have seen more discussion around turning assessment results into meaningful risk management processes. But alas (as the Rolling Stones said), you can't always get what you want.

Document Release and the SCAP Conference

Yesterday, NIST released two documents. One is the update to 800-60 (Vol 1 and Vol 2), which assists system owners with identifying the information types and things to consider when categorizing a system.

The other is draft Interagency Report 7511, which describes the process that a tool must go through in order to be SCAP-validated. The italics of course meaning that you should beware that there are/could be tools that say they are compliant not validated. Validated of course meaning that an independent, accredited lab has run through the certification requirements.

Cursory review shows me that the IR 7511 will help all of us understand the criteria to be SCAP validated. I say cursory because I have no intention of going through this document in the near future. It is clearly written for vendors who want to get their product tested and they can use this as the beginning of their requirements management process. Also, their QA teams will certainly implement it before they spend money on testing.

Also coming up is the annual SCAP conference, I went to last year's and it was generally good. I will be going again this year. So, if you aren't going and you want to know what happened leave a comment. If you are going, and you feel like ranting at / with me contact direct: cyberhiker -at- gmail -dot- com.

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.