Is the NTSB a model for incident response?

Sean, are you discussing the incident of HBGary Federal (not HBGary) being hacked, or how HBGary Federal was attempting to 'hack' WikiLeaks et al?

If we are talking about HBGary Federal being hacked, it was hacked by a single point of failure - not multiple error culminating in disaster, as in Flight 191. Someone, despite their training buckled under pressure and short circuited the (presumably existing) process.

The administrator got a call from someone pretending to be Greg Hoglund (part owner), and demanded firewall changes and root access. The administrator Jussi Jaakonaho knew this, as it is mentioned in their e-mail exchange.

If you are talking about HBGary Federal's, in my opinion, unethical behavior there is not much to say. There are always individuals whom lack the character and moral fiber to guide them.

I think the root cause analysis process described in this article is pretty important. I think in the work we do we have all seen these incidents arise from a complex chain of factors that end up being pretty common amongst many different sectors.

IR responders need to create a clear, concise summary of incidents that is easily digestible by the readers (CEOs, CIOs, others). I have been exploring this issue with colleagues and trying to develop a model which provides a summary of incident root causes in a manner that outlines the major points that caused the failure\incident.

I see resistance by the private sector in being forced to do submit to a government IT incident inspection body. But perhaps if multiple groups and agencies banded together to identify the major components required of a infosec investigation that should be addressed it could become the required standard via PCI, HIPAA, and various other regs and customer\investor\insurance requirements.

This also makes me think of a great book I am reading "The Checklist Manifesto" by Atul Gawande. Great book I recommend it for any professional and it has application to this arena.

Sean, are you discussing the incident of HBGary Federal (not HBGary) being hacked, or how HBGary Federal was attempting to 'hack' WikiLeaks et al?

If we are talking about HBGary Federal being hacked, it was hacked by a single point of failure - not multiple error culminating in disaster, as in Flight 191. Someone, despite their training buckled under pressure and short circuited the (presumably existing) process.

Please read the link embedded in the article. I was commenting on the analysis which was referenced in the link. In that link, it is clear that the targets were both HBGary and HBGary Federal and that there were multiple vulnerabilities. For example, the sentinel event was the SQL injection which led to Anonymous gaining access to the database underlying HBGF's content management system.

But there were also weaknesses in the implementation of the encryption for the passwords in the database (which, had it been stronger, would have limited the subsequent damage), and these, coupled with the fact that key individuals used simple passwords, allowed the passwords to be guessed.

Another weakness was the fact that these same individuals used the same passwords on multiple systems (including external, social, networks), allowing these systems to be exploited, as well. Again, had different passwords been used for different systems (or two-factor authentication), subsequent exploits would not have been possible.

Knowledge of the passwords allowed Anonymous to access support.hpgary.com and, through privilege elevation (due to a GNU C compiler bug which had not been fixed on the support system). The article implies that privilege elevation allowed the user to learn sufficient information to successfully compromise HBGs email hosted at Google Apps.

AT THIS POINT (according to the article), social engineering was used for, essentially, the last step.

This was not (according to the article that I referenced), a single vulnerability issue but an issue of individual vulnerabilities used to create a massive exploit.

Heh. My apologies.

I read an other article on arstechnica, and I presumed from the link that you were referencing that article.

Heh. My apologies.

I read an other article on arstechnica, and I presumed from the link that you were referencing that article.

No problems. I, too, read a number of postings none of which was as detailed as the analysis that I referenced. When I read, it reminded me of other incidents that we have handled in which a combination of factors was responsible for the outcome which would not have happened if any one of them had not been exploited.

As an aside, long before digital forensics became a more or less exclusive line of work my company developed web-based applications. In the spring of 1998 we developed a production Web based application for entering food safety inspection data using PHP. Certain that we had thoroughly tested it, we released it for use by the field inspectors. Within days we were getting complaints that some data were missing from the database. PHP has an option where you can turn off error reporting to the browser so the users were unable to tell us what they were doing when problems occurred.

We found the bad records and interviewed the users and discovered that we had not taken into account the use of non-alphanumeric characters. When we turned on error reporting, it was clear that, under certain circumstances, what the user entered ended up modifying the SQL query. In essence, we were seeing unintended SQL-injections.

Of course, we didn't call it that and viewed it as an annoyance rather than a potential threat because it meant adding code to every text box/area to screen out inappropriate characters.

Who, after all, would deliberately include SQL operands into queries involving the names of restaurants?

Later that year, SQL injections were first described, publicly, in this article by Rain Forest Puppy.

I think many of the great buffer overflow exploits were enabled because the programmers thought "Now why would anyone want to do that?"

Sean,

I just joined this group and so I just now read your article and the recounting of Flt. 191 triggered a memory.

Back in the day, when I was a young newspaper reporter, I covered that crash and was the first journalist on the scene because I was riding my bike headed for home (located 12 miles from O"Hare) when the FAA's news bulletin hit the radio news. I had actually just crashed the bike and was picking myself up off the street when a woman came running out of her home in a panic. She asked if I was all right (yes) and then exclaimed her horror over the news bulletin of the crash. I sped home, jumped in my car, and flew down the the expressway shoulders all the way to O'Hare.

I interviewed many bystanders in the terminal, and also the friends and family members who were called to return to the airport as they were on their way home after dropping people off to catch the flight. Through my stupidity, after infiltrating the private queue of family/friends called back to a secure conference room to meet with AA officials, the person in front of me was asking about survivors and I naively responded that there were none, "Didn't they tell you?". I was horrified to see how my quiet response was telegraphed down the line of 100s of people, who each turned in shock to look at me, and then burst into tears. AA had yet to provide any crash details and these people did not know that all aboard were presumed dead. I was the idiot who stupidly broadcast it to them all in the most hamfisted of ways. What a terrible feeling I had, and how sad for them to learn this from an idiot neophyte reporter who didn't know the first thing about interviewing under these conditions.

That was more than 30,000 interviews ago, and after 24 years in that profession, and 10+ in the field of government and private sector investigation, with much much training and experience in interviewing and interrogation, deception detection, etc., I have gotten much better at it. But I will never, ever forget the harm that I did and the pain that i caused that day.

As you point out, a confluence of failures led to the disaster and death toll.

I can still remember/visualize the crash field from the airport to the Oasis mobile home trailer park.

This message has nothing to do with forensics, but your post took me back to a shared, albeit sad, event.

Gil

I think it is important to think outside the box and be a bit of a cowboy in any area of IT. I am also of the opinion that there should be standard operating procedures for the very reasons you describe in your article.

I also think that there should be better transparency when incidents happen. Transparency in the sense that the cause, effect, and resolution of an attack or systems failure are shared with the community. Names may be changed to protect the innocent, or in some cases the ignorant.

I have had the discomfort of working with people who do not follow procedure and when they balk at my concern I ask them if they would buy a car from a company that doesn’t follow a specific workflow or one that has an assembly line that does the same job the same way every time.

This is off topic but…
It would be interesting if software users started filing suit against software companies for security holes that result in intentional or unintentional data loss?

Greetings,

I am fairly certain that EULA's prevent the end user from filing suit against software companies for losses due to most anything imaginable. I've not read one in years, but if you ever search for EULA in a Windows image, you'll find more than a few of them.

-David

Greetings,

I am fairly certain that EULA's prevent the end user from filing suit against software companies for losses due to most anything imaginable. I've not read one in years, but if you ever search for EULA in a Windows image, you'll find more than a few of them.

-David

I can dream. Can't I? <smirk>