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…