“Drawn” by an infosec engineer known simply as “TomBot” and passed down in email for years.  Click the diagram to get a bigger version.

Network Diagram by TomBot.

• Et Tu, TIC?
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2
• When Standards Aren’t Good Enough
• Security Assessment Economics
• A Step Inside the Guerilla CISO’s Mind

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

Rybolov really struck a note with me (as he usually does) with his blog entry with his decision that S.3474 was a bad thing. It reminds me of a conversation I had with a friend recently. Basically she ask me why bad thing happen even after smart people put their heads together and try to deal with the problem before facing a crisis. Intrigued with her question, I asked her what specifically she was asking about. She shared that she had been thinking about the tragedy of the Titanic sinking.

Of course she was referring to the sinking of the passenger ship RMS Titanic on the evening of 14 April 1912. She made two points, first that the experts declared that the ship was “unsinkable” – how could they be so wrong. Second, she wondered how the ship could be so poorly equipped with boats and safety equipment such that there was such great loss of life.

The Titanic’s Disaster photo by bobster1985.

Little did she know that I have had an odd fascination with the Titanic disaster since childhood and have basically read much of the common public material about the event. So, I replied that that no expert had ever declared her unsinkable, that it was basically something that was made up by the press and the dark spineless things that hang around the press. However, I added the designers and owners of the ship had made much of her advanced safety features when she was launched. A critical feature was including water-tight bulkheads in her design. This was something of an advanced and novel feature at the time. What it meant was that you could poke a pretty big hole in the ship, and as long as the whole was not spread over several of these water-tight compartments she would stay afloat. The problem was that the iceberg that she hit (the Titanic, not my friend), ignored all of this a tore a big gash along about a third of the length of the ship.

So, my friend pressed again about the lack of safety equipment, especially lifeboats. I told her that the problem here was that the Titanic indeed did meet all of the safety requirements of the time. And that a big part of the problem was that the safety requirements were drafted in 1894 at a time when there were rapid changes and in the size and design of ships of this kind. Those regulations indicated that all passenger ships over 10,000 tons required 16 life boats, and that’s how many the Titanic had. At the time the regulations were written there were hardly any ships over 10,000 tons in size. However, when Titanic was launched she was designed to be over 50,000 tons when fully loaded. The fact was that if each of these lifeboats was fully loaded they could barely hold half of the of the passengers and crew of the ship if fully loaded. What is worse, when the ship did sink, not all of the boats were usable because of speed and angle in which the ship began sinking.

So, the bottom-line was that when the Titanic was reviewed by the safety accountants, they took out their check-list and went over the ship with a fine tooth comb. When the day was done the ship fully met all the safety criteria and was certified as safe.

This is where I see the parallels between root causes of the Titanic disaster and the odd situation we find ourselves in today in terms of IT security. Security by checklist –especially out of date checklists—simply doesn’t work. Moreover, the entire mental framework that mixes up accounting practices and thoughts with security discipline and research is an utter failure. Audits only uncover the most egregious security failures. And, they uncover them at a point in time. The result is that audits can be gamed, and even ignored. On the other hand, formal reviews by experienced security professionals are rarely ignored. Sometimes not all of the resources are available to militate against some of the vulnerabilities pointed out by the professionals. And sometimes there is debate about the validity of specific observations made by security professionals. But, they are rarely ignored.

Interesting enough, because of the mixed IT security record of many government agencies, Congress is proposing – more audits! It seems to me what they should be considering is strengthening the management of IT security and moving from security audits often performed by unqualified individuals and teams toward security assessments conducted by security professionals. And since professionals are conducting these proposed assessments, they should be required to comment on the seriousness of deficiencies and possible mitigation actions. An additional assessment that the professionals should be required to report on is the adequacy of funding, staffing and higher management support. I don’t really see any point in giving a security program a failing grade if the existing program is well managed but subverted and underfunded by the department’s leadership.

• FedRAMP: It’s Here but Not Yet Here
• In Other News, I’m Saying “Nyet” on S.3474
• GAO’s 5 Steps to “Fix” FISMA
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2
• “Machines Don’t Cause Risk, People Do!”

I love transition time.  We get all sorts of strange people who come in, issue their letters on how they think the Government can solve the major cybersecurity issues for both the Government’s IT systems and for the rest of the US as a whole.  And then, they all leave.

Nobody actually implements the suggestions because it takes time, effort, and money to get them done, and all that anybody ever wants to give is talk.  Talk is cheap, security is not.

Many years ago when I became an infantryman, our guest speaker at graduation made one of the most profound statements that I remember over 8 years later: “Infantrymen vote with their feet”. In other words, we’re doers, not talkers, and at one point in our lives we decided that something was important enough to give up 4 years of our lives, maybe more, for this cause.  Even Colonel Davy Crockett after he lost re-election to the House of Representatives wrote “I told the people of my district that I would serve them as faithfully as I had done; but if not … you may all go to hell, and I will go to Texas.”  He died less than 3 years later at the Alamo.  That, ladies and gentlemen, is how you vote with your feet.

My personal belief is that the primary problem the Government has with security (on both sides of the InfoSec Equities Issue) is that there is a lack of skilled security practitioners upon which to draw from.  If you think about everything we’ve done to date, it’s almost always a way of compensating for our lack of skilled people:

• Reducing security to a bunch of checklists
• Providing templates to non-security staff
• Automation wherever possible
• “Importing” non-security specialists such as accountants and technical writers in security roles
• Building a “Franchise Kit” upon which to base a security program
• Reserving key decisions for trained security staff

As an industry, we have failed (at least in the public sector) at generating people with the skills to do the job.

And in light of this, my challenge to you:  have a good idea and think you know how to solve the information security?  Yes, we need those, but what we really need are IT security infantrymen who are willing to be doers instead of talkers.  To answer the title of my blog post, the thing that the Government is missing is you.

Infantry Action Photo by Army.mil

So how can you help?  I know moving to DC is a bit of a stretch for most of you to do.  This is a short list of ideas what you can do:

• Learn how the Government secures systems: don’t just dismiss outright what people in DC are doing because conventional wisdom says that it is failing miserably, and don’t listen to people who do the same.
• Actively recruitment of techies to “embrace the dark side” and become security people:  We need more technically-savvy security people.
• Answer the call from DHS when it comes: living in DC is isolating from the rest of the world and all fo the good ideas that are out there.  Maybe you have a phenomenal microstrategy on how to secure IT.  They/we need to know them.  The Government cannot succeed at securing cyberspace (whatever your interpretation of that phrase means) without input from the private sector.
• Don’t engage the Government only when there’s money in it for you. ~$8B is a ton of money, but if you’re doing your job right as a vendor, you’re solving their problems as a first priority, not a second.
• Build a better education system for security staff and make better career paths to get people from the technical disciplines into security.

• Inside the Obama Administration’s Cyber Security Agenda
• Now ISC2 Blogs have an Opinion on FISMA
• In Other News, I’m Saying “Nyet” on S.3474
• Cyber Security coming to a boil
• A Step Inside the Guerilla CISO’s Mind

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