CAG Fever… we haz it here at Guerilla-CISO.  So far the konsensus is that CAG works well as a “Best Practices” document but not really as an auditable standard.  We’re thinking that CAG will provide the rope with which our IGs and GAO will hang us.

• CIO Council Guidelines on Social Media Meet IKANHAZFIZMA
• LOLCATS Take on MS08-67
• Shmoocon: Less Moose, More LOLCATS
• Guerilla CISO Goes Back to Work
• IKANHAZFIZMA Finds Caution Tape

Did you know that the US Department of Defense published the Consensus Audit Guidelines?  Yes, it’s true!  At least according to a ZDNet UK article title, “US Dept of Defense lists top 20 security controls“.

There is a haze of confusion settling around the Consensus Audit Guidelines origins.  The text of the CAG press release (pdf) is clear that it is developed by a consortium of federal agencies and private organizations.  It further states CAG is part of the Center for Strategic and International Studies work on CSIS Commission report on Cybersecurity for the 44th Presidency.  The title of the CAG press release is also equally clear that it is from a “Consortium of US Federal Cybersecurity Experts” which is substantively different than a consortium of federal agencies and private organizations.

The press release relates that CAG was initiated when a team discovered similarities between massive data losses by the US defense industrial base (DIB) and attacks on Federal agencies.  The project then grew as more agencies agreed to become involved.  Following the current public review of CAG the next steps for development are listed as pilot implementations at government agencies, a CIO Council review and an IG review. The clear inference of this origin story and ennumeration of steps is that the project has official Federal backing.

Let’s test that inference.  Click here for a Google search of the entire *.gov hierarchy for “Consensus Audit Guidelines”.  As I write this there is exactly one entry.  From oregon.gov.  A search using usa.gov (which uses live.com) has the same results.  Looking around the various organizations listed as contributors doesn’t yield any official announcements.

So why the confusion in the press?  Why does it appear from the news articles that this is an Federal project?  I wouldn’t speculate.

On a slightly different topic, I’ve been reading through the Consensus Audit Guidelines themselves and enjoying the guidance it provides.  I’ll write up a more complete analysis of it once I have finished my read through.  My initial impression is that CAG controls provide worthwhile recommendations but the framework for implementation needs development.

All Aboard the Astroturfmobile photo by andydr.  Perhaps an explanation is in order….

• The 10 CAG-egorically Wrong Ways to Introduce Standards
• In Response to “Cyber Security Coming to a Boil” Comments….
• “Machines Don’t Cause Risk, People Do!”
• 20 Critical Security Controls: Control-by-Control
• Keeping The Lights On: Cybersecurity Law for the Electric Grid

At the beginning of the year, I was absolutely tickled pink: I almost had a copycat.

The NinjaCISO blog was started shortly after the new year and seemed interesting in what they had to say over the next couple of months.  I eagerly waited for their every post, wondering what kind of insight the Ninja would come up with next.  Since for the most part we operate in unchartered waters here at the Guerilla-CISO, it sometimes is nice to get different points of view so we don’t feel like we’re some kind of bizarre Government information security self-licking ice cream cone.

Then in mid-February, the whole blog was replaced with a cartoon saying that “On the Internet, nobody knows that you’re a dog”.  This can mean only one thing:  the Ninja was given a cease-and-desist by their chain of command and was forced to commit blog seppuku.  And the blogging world experienced a small void.

Nobody Knows You’re a Dog lifted from NinjaCISO.com.

See, dear readers, this is a problem for Government employees who blog.  Let’s look at a little bit more extreme example: military bloggers (milblogs).

You see, the military has gone back and forth on this a couple of times.  In April 2007, the Army decided that soldiers shouldn’t blog without notifying their commander, (clarified here) and the Global War Against Blogs was started, much to the dismay of a lot of clueful people who understand the value that blogs bring to the DoD.

Yes, Joe is dumb.  Joe talks about stuff that he shouldn’t really talk about.  But Joe can also talk about the village in Afghanistan where he’s a local hero because he rescued a policeman while he was being held hostage.  Joe can also talk about the school that the Taliban burned and how US money and some “local matching funds” from the Provincial Governor brought carpets, pens, and pads of paper so that the kids could continue to learn how to read and write.

And this is the conundrum: in a war where the “bad guys” are winning the media war, how do you give a voice to the guys doing good things but just enough so that they don’t talk about anything that you don’t want them to–troop movements, physical security problems, and how they really feel about the administration’s policies?

And so back to my real message here:  we as an industry need to hear from the invisible people who make information security in the Government work.  Otherwise, you would think that FISMA is failing, Government CISOs are a bunch of buffoons who don’t know how to get a good report card, DHS is monitoring the Interwebs looking for the next Nick Haflinger, and the only people getting any benefit out of the way we do information security is a bunch of fat-cat contractors and their shareholders. (Side note, how do I sign on for this contractor wealth thing?  I must be doing it all wrong.)

We now have an administration that talks about openness, transparent democracy, and all this Government 2.0 stuff.  Truth be told, I don’t think anybody has thought about extending that transparency to trickle down to the “worker-bees”.  These are really 2 different issues: official blogs v/s personal blogs that might be career-related.  I think we have a pretty good handle on the official blogs, but there is a huge void of policy in the realm of personal blogs.

Message to the administration: what we want and need is a blog policy for Government employees that works like this:

• Don’t use your title or agency in anything you write
• Don’t use Government IT resources (desktops, servers, or network) to blog
• Don’t blog at work on the clock as a Government employee
• Do use a pseudonym if at all possible
• Do not violate the Hatch Act with your blog
• Do try to blog objectively about policy issues
• Do talk about your successes
• Do encourage others to make the Government the best that it can be
• Do offer suggestions to problems

As for the NinjaCISO’s content, you can catch bits and pieces of it here on Technorati.

Orwell’s Reporter Lady Goldstein photo by Boris from Vienna.  For clarification, we’re not talking 1984-type things here folks, this is just the blagosphere.  However, it is a funny picture.

• What’s Missing in the way the Government does Security?
• Needed: Agency CSOs
• An Open Letter to NIST About SP 800-30
• On Why I Blog… FUD is the Reason for the Writin’
• The World Asks: is S.773 Censorship?

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…

While I’ve been busy running all over the US and Canada, I missed a quasi-momentus date: the second anniversary of the Guerilla-CISO.  You can read the “Hello World” post if you want to see why this blog was started.

Blah Blah blah much has happened since then.  I swapped out blog platforms early on.  I started playing the didgeridoo.  I went on a zombie stint for 9 months.  I switched employers.  I added FISMA lolcats (IKANHAZFIZMA).  I started getting the one-liners out on twitter.  Most momentous is that I’ve picked up other authors.

• Ian Charters (ian99), an international man of mystery, is a retired govie with a background in attacking stuff and doing forensics.
• Joe Faraone (Vlad the Impaler), besides being a spitting imitation of George Lucas, is the guy who did one of the earliest certification and accreditations and informally laid down some of the concepts that became doctrine.
• Dan Philpott (danphilpott), Government 2.0 security pundit extraordinaire, is the genius behind Fismapedia.org and one of the sharpest guys I know.
• Mini-Me, he’s short, he’s bald, and he guest-blogs from time to time about needing a hairdryer.

So in a way, I’ve become “the pusher”–the guy who harrasses the other authors until they write something just to quiet me up for a couple of weeks.

• Digital Forensics and the case for change
• How I Became the Owner of Two Rogue WiFi APs
• Lousy Security Advice
• What’s Missing in the way the Government does Security?
• An Informal Study on the Literacy Level of Security Blogs–We All Get Pwned by Amrit

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!”