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 New 800-37

Attention everyone: the 800-37 Rev 1 has gone final! I think I may re-cap the changes in this forum. We'll see if that actually comes together.

http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

Out.

ShmooCon

I will be at ShmooCon February 5th until the 7th. By luck, I managed to get a room at the last minute.

Hit me on twitter at http://twitter.com/cyberhiker during the event. Even if you just want a snowfall report.

Technology Death Pronouncment

I haven't seen much of the Firewalls, Anti-Virus and IDS are Dead technologies recently, Mind you I have been extremely busy with other things of late.

The short version is that I am ready to proclaim that nothing is dead. That's right. No matter how hard we try to get away from mainframes or Windows NT or whatever. Most of us have to deal with things on a regular basis. So get over it.

What should be dead is calling different technologies dead. Especially since there will always be a reason to use whatever "it" is, even if the reason is a bad one.

There are couple reasons for this. The finance guys don't have a lot of patience for needing to spend $1 Million at the beginning of the year and then reading in *Business* magazine by *expert* that *technology* is now on a slab.

The reality of it is that the uninitiated gets upset. It also upsets me. But for different reasons. Here are a group of people (security staff) in a company who have probably fought for months to bring something in, get it installed and operating. Only for some blow hole to come through and make an uninformed opinion about everyone's environment.

The aforementioned blow hole comes with credibility, because they are published. The people on staff probably not. I don't hate the blow hole though because they are trying to sell magazines and announcing the death of whatever sells X publication.

It all comes down to profiling the risks to your organization. If you are a decision maker, take advice from industry rags with a grain of salt. If you are in the trenches, be sure that your business cases are tight and the deciders know what the technology does and the risks it is mitigating.

That is all.

Which brings me to tonight's word: Complianciness

Much like the way that Stephen Colbert uses Truthiness, where it is not the actual truth but “the quality of preferring concepts or facts one wishes to be true, rather than concepts of facts known to be true”. Complianciness is not actually compliance, but that you want to believe that you are compliant rather than actually being compliant.

This word evolved from a conversation with a number of highly regarded professionals (Mike Smith, Dan Philpott and Graydon McKee), with shout-outs to Chris Hoff and Anton Chuvakin for a twitter exchange around measurements (I believe this post is worth 286,497 Chuvakins).

And here (I believe) is one of its best examples:

Recently, Bob Carr (CEO of Heartland Payment Systems) gave a podcast interview to Bill Brenner at CSO Online. During this interview, Carr basically threw his Qualified Security Assessors (QSA) under the bus. He had equated what the QSA is responsible for doing (measuring Heartland against the PCI controls) for actual secure operations. There are two sides to this story I am sure, however I like to think of PCI-DSS as a “tech heavy” control set. To me this means that the controls are very focused on securing the technology but that it could still be maintained or operated poorly. That also means, that the QSA is focused on a very specific set of controls, not on Information System Risk Management (although it does mandate an annual risk assessment).

Carr asserts that the QSA assessments were not helpful for the years that he had to pay for it. I would argue that they were helpful because it showed Visa and Mastercard that Heartland had implemented a minimum set of controls to protect some information for Visa and Mastercard.

Where's the complianciness? Heartland Payment Systems – based on my research of the situation Heartland may have been PCI compliant at the point in time that they were assessed. It could be that security was a little more lax when the assessors were not inbound to conduct testing. It also might have been that a very elaborate show was put on for the assessors and they were not actually compliant, but perhaps practicing complianciness.

Question from the Audience: I thought you only talked about FISMA, where is the complianciness there?

A: Thank you random voice in my head.

It is rampant. FISMA / OMB / NIST Guidance all used come back to one thing, Information System Risk Management. The process of identifying risks to your mission or system and then applying a specific set of policies and controls to mitigate those risks. What has evolved from this, and I only have anecdotal evidence / hearsay to back this up, is that integrators, developers and operators are being told to simply follow NIST guidance. When that is entirely not possible without making some decisions by the customer.

NIST guidance is there to provide options and support. It can lay out things to consider and questions you should be asking yourself. The policies, procedures and processes that are carried out on an information system must be clearly defined at the beginning of the design process by being built into the design requirements.

I feel like now is the best time to mention these ideas because many organization in the government are going to be reviewing NIST 800-53 Rev 3, and having to make some decisions about what their policies are going to be for the next couple of years. My response is Choose Compliance not Complianciness.

Telling a vendor to go look at NIST and build it, will only get you what the vendor is willing to provide by shoehorning the solution into the controls. I'll elaborate. Vendor will read the controls. Vendor will either write the SSP or provide input to the Self Assessment. Those result will be their interpretation of the least effort required by that control. As the federal customer, you will believe that they have implemented that control to the strength that you believe it should be implemented. You have therefore practiced complianciness, at least until the auditor or assessor comes in and tells you what is actually happening (you hope). Because the auditor could in fact perceive the controls to be something entirely different altogether.

If you are part of a government agency, you want to provide a policy that can be based on 800-53 but you need to answer the questions it asks.

And that's the word.