A couple of weeks ago I posted a whitepaper, “The History of Digital Forensics”. I am just delighted that Rybolov gave me the opportunity. I am also delighted with all of the comments and question that have come in, in response to the posting of the whitepaper. I want to thank each and every one of you who responded. One of the most common comments or themes is that while I did a fine job of outlining the History of Digital Forensics, many security and forensics professionals find themselves in an organization that has only the most rudimentary forensics policies, procedures or even capabilities. For those of you who offered such comments, you have my complete sympathy.

However, I should also point out that many of the organizations that have well planned and supported digital forensics programs are only in that condition because they have learned of their security and forensics needs the hard way. I think many IT security professionals can relate to my comment when I write that, no one appreciates the need for better security and procedures more than the members of a team that have just completed an incident response without the benefit of sufficient planning and support. Many of us have been there either as a member of an internal as hoc incident response team or as part of a team of outside consultants called in to assist. Incident response is difficult and filled with tension. It is even more tension filled when you are part of a team that is having to invent procedures with each step you make and also defend them in real-time, often with many successive levels of management. The last several incident response engagements I have led, I had no opportunity do any technical work at all. My entire time was spent trying to hammer out processes and procedures and generally educate the management and explain the process for them. Since incident response usually cuts across every part and work-unit in an organization, each with its own way of looking at things, and with its own interest and concerns, the process also involved a lot of repetition, sensitivity and frankly hand-holding. I have never had a technical member of the team say they envied me in that role.

However, in each case, an important part of my mission was also to document the policies, procedures, and ‘lessons-learned’ and act as an advocate to incorporate this body of knowledge into standard operating procedures. In some cases I was successful; in others I think the organization was so traumatized by the incident itself that they were burnt-out and incapable of taking the next step at that time. Fortunately, many of the later contacted me later and we had some wonderful meetings in a pretty relaxed and yet focused atmosphere.

I guess, in part what I’m trying to make two points here, first is that even in the thick of it, you should always take a mental step or two back and take in the bigger picture. The second point is that when you are acting as an advocate trying to advance the progress of a security or digital forensics program, always put a solution in from of your management, never a problem. And to make it easier for your manager to pick up the ball and support your idea at the next level, make sure that you make a business case for plan, not a technical case.

In the post-incident world, the window of opportunity for change is small. Senior managers and business leaders must get on with their day-to-day business responsibilities. Dwelling on a security incident is counter-productive for them. However, their receptiveness to change in the form of well reasoned and prudent measures that are integrated into the business process is great. Making the case for security is perhaps the most important part of our job. We must always make the case when the opportunity for change presents itself.

US Cryptologic Museum Pueblo Incident photo by austinmills.  More information about the Pueblo Incident is here.

• It’s a Blogiversary
• Guerilla CISO Tip: Get Inside the Data Center
• Could the Titanic have changed course?
• The Spanish Civil War and the Rise of Cyberwar
• Some Thoughts on Comments to My Blog…

The Consensus Audit Guidelines (CAG) appear, at this point, to be a reasonable set of guidelines for mediating some human threats. I’m looking forward to seeing what CAG offers and have no doubt there will be worthwhile and actionable controls in the document. That said, there are significant reasons approach CAG with skepticism and assess it critically.

The motivation for CAG is described in a set of slides at the Gilligan Group site. It starts with a focus on what CIO’s fear most: attacks, reduced operational capability, public criticism, data loss, etc. Then it rightly questions whether FISMA is adequately addressing those problems. It doesn’t and this is the genesis of the CAG.

Consensus photo by Eirik Newth.

Unfortunately CAG subsequently develops by pairing this first valid premise with a set of false premises.  These propositions are drawn from slides at gilligangroupinc.com, attributed to John Gilligan or Alan Paller:

1. All that matters are attacks. The central tenet of Bush’s Comprehensive National Cyber Initiative (CNCI) is adopted as the CAG theme: “Defense Must Be Informed by the Offense”. CAG envisions security as defense against penetration attacks. As any seasoned security practitioner knows, attacks are a limited subset of the threats to confidentiality, integrity and availability that information and information systems face.
2. Security through obscurity. CAG seems to have taken the unspoken CNCI theme to heart too, “The most effective security is not exposed to public criticism.” Since its very public December 11th announcement no drafts have been made publicly available for comment.
3. False dichotomy. CAG has been promoted as an alternative to the OMB/NIST approach to FISMA. It isn’t. An alternative would target a fuller range of threats to information and information system security. CAG should be considered a complement to NIST guidance, an addendum of security controls focused on defense against penetration by hackers. NIST has even acted on this approach by including some CAG controls into the 800-53 Rev. 3 catalog of controls.
4. There is too much NIST guidance! This is the implication of one CAG slide that lists 1200 pages of guidance, 15 FIPS docs and the assorted Special Publications not related to FISMA as detriments to security. It’s like complaining that Wikipedia has too many articles to contribute to improved learning. Speaking as someone who scrambled to secure Federal systems before FISMA and NIST’s extensive guidance, having that documentation greatly improves my ability to efficiently and effectively secure systems.
5. NIST guidance doesn’t tell me how to secure my systems! NIST’s FISMA guidance doesn’t step you through securing your SQL Server. The Chairman of the Joint Chiefs also doesn’t deliver your milk. Why not? It’s not their job. NIST’s FISMA guidance helps you to assess the risks to the system, decide how to secure it, secure it accordingly, check that a minimum of controls are in place and then accept responsibility for operating the system. NIST also provides documents, checklists, repositories, standards, working groups and validation of automated tools that help with the actual security implementation.
6. Automated security controls negate human errors. With the premise of all threats being attacks this is nearly a plausible premise. But not all security is technical. Not all threats come from the Internet. DHS, NIST, Mitre, and their partners have pursued automated security controls to enforce and audit security controls for years but automated security controls can only go so far. Human errors, glitches, unexpected conflicts and operational requirements will always factor into the implementation of security.
7. Audit compatibility as a hallmark of good security. There is a conflict of focus at the heart of the CAG, it seeks to both improve its subset of security and improve audit compatibility. For technical controls this is somewhat achievable using automation, something NIST has pursued for years with government and industry partners. For operational and management controls it results in audit checklists. But audits are fundamentally concerned with testing the particular and repeatable, security needs focus on evaluating the whole to ensure the necessary security results. An audit sees if antivirus software is installed, an evaluation sees if the antivirus software is effective.
8. Metrics, but only these metrics over here. When selecting the current crop of CAG controls decisions on what to include were reportedly based on metrics of the highest threats. Great idea, a quantitative approach often discovers counter-intuitive facts. Only the metrics were cherry picked. Instead of looking at all realized threats or real threat impacts only a count of common penetration attacks were considered.
9. With a sample of 1. As a basis for determining what security should focus on the whole breadth of the security profession was queried, so long as they were penetration testers. Yes, penetration testers are some very smart and talented people but penetration testing is to security what HUMINT is to intelligence services. Important players, expert practitioners but limited in scope and best used in conjunction with other intelligence assets.
10. Assessments rely on paper artifacts. The NIST guidance does not require paper artifacts. The first line in the NIST SP 800-53A preface is, “Security control assessments are not about checklists, simple pass-fail results, or generating paperwork to pass inspections or audits-rather, security controls assessments are the principal vehicle used to verify that the implementers and operators of information systems are meeting their stated security goals and objectives.” NIST SP 800-37 specifically and repeatedly states, “Security accreditation packages can be submitted in either paper or electronic format.”

CAG is a missed opportunity. Of the myriad problems with our current FISMA regime a lot of good could be achieved. The problems with guidance have many causes but can be addressed through cooperative development of best practices outside of NIST. The Assessment Cases for SP 800-53A is an example of how cooperative development can achieve great results and provide clear guidance. Other problems exist and can be addressed with better training and community developments.

My hope is that the Consensus Audit Guidelines will move towards a more open, collaborative development environment. The first release is sure to deliver useful security controls against penetration attacks. As with all good security practices it will likely need to go through a few iterations and lots of critical assessment to mature. An open environment would help foster a more complete consensus.

Consensus photo by mugley.

• Clouds of CAG Confusion
• A Funny Thing Happened Last Week on Capital Hill
• How to Not Let FISMA Become a Paperwork Exercise
• When Standards Aren’t Good Enough
• “Machines Don’t Cause Risk, People Do!”

It’s probably a shocker to most people, but I’m going to recommend that S.3474 be amended or die on the Senate floor like Caesar.

I’ve spent many hours reading over S.3474.  I’ve read the press releases and articles about it.  I’ve had some very difficult conversations with my very smart friends.

I’ve come to the conclusion that S.3474 as written/proposed by Senators Carper and Leiberman is not the answer to information security in the Government as it has been publicized repeatedly, and that anyone who believes the hype is in for a rude surprise next fall if the bill is ratified and signed.

My thoughts on the matter:

• S.3474 is not what it is being publicized as.  The people who write the press releases and the articles would have us believe that S.3474 is a rewrite of FISMA 2002 and that it focuses on continuous monitoring of the security of IT systems, both of which are a good thing.  First and foremost, it does not repeal FISMA 2002, and anyone saying that is simply trying to deceive you.  S.3474 adds to the FISMA 2002 requirements and codifies the role and responsibility of the agency CISO.
• S.3474 does not solve the core problem.  The core problem with security and the Government is that there is a lack of a skilled workforce.  This is a strategic issue that a bill aimed at execution of security programs cannot solve by itself.
• S.3474 adds to the existing checklists.  People have been talking about how S.3474 will end the days of checklists and auditors.  No, it doesn’t work that way, nor is the bill written to reduce the audits and checklists.  When you introduce new legislation that adds to existing legislation, it means that you have added more items to the existing checklists.  In particular, the provisions pertaining to the CISO’s responsibilities are audit nightmares–for instance, “How do you maintain a network disconnect capability as required by FISMA 2008” opens up a whole Pandora’s Box worth of “audit requirements” which are exactly what’s wrong with the way FISMA 2002 has been implemented.
• S.3474 puts too much of the responsibilities on the CISO.  It’s backwards thought, people.  The true responsibility for security inside of an agency falls upon that political appointee who is the agency head.  Those are the people who make the decisions to do “unsafe acts”.
• S.3474 does not solve any problems that need a solution.  Plain and simple, it just enumerates the perceived failings of FISMA 2002.  It’s more like a post-divorce transition lover who is everything that your ex-spouse is not.  Let’s see… technical controls?  Already got them.  Requirements for network monitoring?  Already got them.  2nd party audits?  Already got them.  Requirements for contractors?  Already got them.  Food for thought is that these exist in the form of guidance, does the security community as a whole feel that we need to take these and turn them into law that takes years to get changed to keep up with the pace of technology?  There is some kind of segue there into Ranum talking about how one day we will all work for the lawyers.

Of course, this is all my opinion and you can feel free to disagree.  In fact, please do, I want to hear your opinion.  But first and foremost, go read the bill.

i haz a veto pen photo by silas216

• Ooh, “The Word” is out on S 3474
• Next Up in Security Legislation: S3474
• Could the Titanic have changed course?
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2
• Senate Homeland Security Hearings and the Lieberman-Carper-Collins Bill

So, what’s the deal?  Have a look through the following articles:

• Cybereye | Has FISMA improved IT security? Maybe:  It is safe to say we are better off than we would have been without it
• Melding Security
• Experts tackle guidance to stop cyberattacks
• Staffer: FISMA bill will pass in the next Congress

And wow, you would think that either the anti-FISMA cabal was on strike this month.  Even Alan Paller’s comments are toned down.  What gives?

But then again, maybe it’s just all part of the transition honeymoon–if you say things enough times, then eventually somebody picks up on it and recommends it to a committee and then it’s true.

My Bike the Transition Bottlerocket photo by Tom Grundy Photo.

Now at this point I start to get cynical, and here is why.  Everybody agrees that cybersecurity (been working with the Government for too long, I don’t even cringe at the word) is this phenomenally important thing that we all should do something about.  But since it’s a cost, for the most part it never actually happens.

In other words, it’s exactly the same problem that CISOs in private enterprise, the banking industry, and insurance has been dealing with for a “long” time: everybody wants security, but they don’t want to pay for it.

And the last article I have to give y’all today is this one from CIO.com.  Programs and ideas are great and all, but the CISO inside me knows that things won’t get done until there is a budget behind it.  That’s why the National Strategy to Secure Cyberspace hasn’t gone much of anywhere until the standup and subsequent funding of the National Cybersecurity Division and the National Infrastructure Protection Plan (yes, you could argue that they need much more funding than they currently have, but you can’t stand up something that big that fast).

Maybe I’ve come back around to the classic argument: talk is cheap, security isn’t.  And when transition fever comes to the Beltway, everybody has something to talk about.  =)

• Introducing the Government’s Great InfoSec Equities Issue
• In Other News, I’m Saying “Nyet” on S.3474
• A Funny Thing Happened Last Week on Capital Hill
• FISMA Report Card News, Formulas, and 3 Myths
• “Machines Don’t Cause Risk, People Do!”

Federal Computer Week: Senate Panel Rejects Weakening S 3474

Gene Schultz: Goodbye FISMA (as We Know It)

Let’s talk through the FCW article first, shall we?   =)

“The measure would amend the original FISMA legislation, which outlined compliance activities for agencies to meet each year. However, many agencies have turned FISMA compliance into a paperwork exercise, Carper said.”

Um, no, I don’t get that.  The original FISMA is an information security management law, this law mostly formalizes the role, responsibility, and authority of the CISO.  They intentionally named it FISMA 2008 to make people think that it was ammending the original FISMA, but it doesn’t do that.

Don’t believe the hype, this will not change the original FISMA, it’s just an addition.

“Carper said CIOs primarily develop and oversee policy, but the CISO handles the daily information security activities. He suggested that a CISO council could have a sunset date of two or three years. If the council demonstrated benefits, it could be extended, Carper said.”

OK, fair enough on the cost and coordination, but what the CISO council objectionists don’t understand is that the CIOs don’t know all of the nuts and bolts of security, that’s why we have CISO as a mandatory position in this bill–so that the CIO has a subject-matter-expert to help them out.  Yes, it’s that specialized as a profession.

Now for Gene Schultz:

“First and foremost, to comply with this statute involves generating huge amounts of paperwork to document actions (or lack thereof) taken to address the many areas that FISMA describes. A completely ineffective security practice can get high FISMA marks, as has happened numerous times before.”

OK, this is a little lesson on FISMA paperwork:  people are doing 4x what they should be doing for the following reasons:

• The people doing the writing do not know what they are actually doing
• The agency’s security program is not mature enough to have shared/common controls
• In the world of auditors, if it’s not written down, it doesn’t exist
• CYA purposes–I told you this was a risk

So you think you’re going to do any better with any other framework/law and the same people executing it?

“Two US Senators, Joseph Lieberman of Connecticut and Tom Carper of Delaware, have recently introduced a Senate bill that would render the 2002 version of FISMA obsolete.”

No, to be bluntfully honest, the old version of FISMA will still be around.  Somebody’s been drinking the kool-aid from the lawmakers and the press machine.  If anything, this adds more junk that you can get audited on and an additional layer of paperwork to demonstrate that you have met the provisions of FISMA 2008.

Post No Bills photo by striatic.

Note to our nation’s Lawmakers: as long as you approach information security from the compliance angle, we as a government are doomed to failure and to turn the entire thing into the checklist activity because the people who evaluate compliance are auditors who only know checklists–it’s not a law problem, it’s a people and skills problem.

This bill is actually pretty good with the exception of divorcing the mission owners from the security of the systems that support their mission.

However, if you think that you can reduce the compliance trap by adding more things that will end up on a compliance checklist, you have to be kidding yourself or you don’t understand the auditor mentality.

I keep reconvincing myself that the only way the government can win at security is to promote programs to develop people with security skills.  Of course, that isn’t as sexy as throwing out a bill that you can claim will make FISMA obsolete.

And finally, for those of you playing along at home, the Thomas entry for S 3474, the bill’s page on Washington Watch and the bill’s page on GovTrack.

• Next Up in Security Legislation: S3474
• In Other News, I’m Saying “Nyet” on S.3474
• Senate Homeland Security Hearings and the Lieberman-Carper-Collins Bill
• A Funny Thing Happened Last Week on Capital Hill
• “Machines Don’t Cause Risk, People Do!”

First, some links:

• Washington Technology
• Federal News Radio
• Federal Computer Week
• The RFI on FEDBIZOPS

Synopsis: DoD wants to know how its system integrators protect the “Controlled Unclassified Information” that they give them.  Hmm, sounds like the fun posts I’ve done about NISPOM, SBU and my data types as a managed service provider.

This RFI is interesting to me because basically what the Government is doing is collecting “best practices” on how contractors are protecting non-classified data and then they’ll see what is reasonable.

Faustian Contract photo by skinny bunny.

However, looking at the problem, I don’t see this as much of a safeguards issue as I do a contracts issue.  Contractors want to do the right thing, it’s just that they can’t decide if security is which of these things:

• A service that they should include as part of the work breakdown structure in proposals.  This is good, but can be a problem if you want to keep the solution cheap and drop the security services from the project because the RFP/SOW doesn’t specify what exactly the Government wants by way of security.
• A cost of doing business that they should reduce as much as possible.  For system integrators, this is key:  perform scope management to keep the Government from bleeding you dry with stupid security managers who don’t understand compensating controls.  Problem with this approach is that the Government won’t get all of what they need because the paranoia level is set by the contractor who wants to save money.

Well, the answer is that security is a little bit of both, but most of all it’s a customer care issue.  The Government wants security, and you want to give it to them in the flavor that they want, but you’re still not a dotorg–you want to get compensated for what you do provide and still make a profit of some sort.

Guess what?  It takes cooperation between the Government and its contractors.  This “Contractor must be compliant with FISMA and NIST Guidelines” paragraph just doesn’t cut it anymore, and what DoD is doing is to research how its contractors are doing their security piece.  Pretty good idea once you think about it.

Now I’m not the sharpest bear in the forest, but it would occur to me that we need this to happen in the civilian agencies, too.  Odds are they’ll just straphang on the DoD efforts. =)

• When the Feds Come Calling
• Splunk Goes After the FISMA Lucre, They’re not Alone
• When the News Breaks, We Fix it…
• Security Assessment Economics
• Surprise Report: Not Enough Security Staff