Calls for an NTSB?

In September, Steve Bellovin and I asked “Why Don’t We Have an Incident Repository?.”

I’m continuing to do research on the topic, and I’m interested in putting together a list of such things. I’d like to ask you for two favors.

First, if you remember such things, can you tell me about it? I recall “Computers at Risk,” the National Cyber Leap Year report, and the Bellovin & Neumann editorial in IEEE S&P. Oh, and “The New School of Information Security.” But I’m sure there have been others.

In particular, what I’m looking for are calls like this one in Computers at Risk (National Academies Press, 1991):

3a. Build a repository of incident data. The committee recommends that a repository of incident information be established for use in research, to increase public awareness of successful penetrations and existing vulnerabilities, and to assist security practitioners, who often have difficulty persuading managers to invest in security. This database should categorize, report, and track pertinent instances of system security-related threats, risks, and failures. […] One possible model for data collection is the incident reporting system administered by the National Transportation Safety Board… (chapter 3)

Second, I am trying to do searches such as “cites “Computers at Risk” and contains ‘NTSB’.” I have tried without luck to do this on Google Scholar, Microsoft Academic and Semantic Scholar. Only Google seems to be reliably identifying that report. Is there a good way to perform such a search?

4 Comments on "Calls for an NTSB?"

  1. By way of clarification (for me), would the following be an article of interest in response to an effective query? The following exhibits the perspective on inhibitions to incident reporting circs 2002.

    From: Global Information Assurance Certification Paper –
    Excerpt: pages 4-5
    Misunderstanding often bars reporting of an incident…
    • Law enforcement investigations may interfere with a corporation’s ability to conduct business. Yes, forensic investigation does take time but capturing a perpetrator removes them from the field and sets an example to others who might not take the chance of hacking a business that is willing to prosecute.
    • Businesses feel a need to minimize publicity in order to protect the corporation or client’s reputation. In some cases, this might seem like a valid business justification but if the truth were ever to leak out the impact to a company’s reputation might not be salvageable. Turn around the situation. Reinforce your corporation’s reputation by taking a definitive stance and positive action.
    • The costs associated with law enforcement investigation, prosecution, and other related business losses might seem high, but in reality allowing an individual to think they have gotten away with something simply increases the number of attacks and sends the wrong message to other perpetrators. This allows them to believe that they will not be prosecuted, even if they are detected and caught.
    • Law enforcement will seize my equipment. Actually, it is the hacker’s computers that are seized not the victims’ equipment. Investigators now use forensic image copies of disks and perform remote searches having far less impact on systems operation. These new advances in forensic investigation have dramatically decreased the need to remove systems from service for extended periods.
    • While competitors might use publicly disclosed information to their advantage, law enforcement agencies generally do not make the details of a case public unless there has been an arrest. In addition, the Freedom of Information Act exempts from release certain information required by government agencies during an investigation.
    • Privacy concerns sometimes drive businesses to seek civil remedies over criminal prosecution. This is because civil suits generally do not require the public release of information. …

    1. Hi Dennis! Good to see you at RSA! I appreciate all the feedback, and what I was looking for right now was even simpler: where are the original recommendations? I’ve edited the post to clarify, but this is great stuff that I was going to ask for in the next round. You’re thinking ahead again!

  2. Another dimension may be shifting guidance on cyber security incident disclosure, for example:

    2011 Expectations of the SEC on public company disclosures :
    Even so, materiality is still going to a big issue, and not every breach will need to be reported as many/most will not likely involve the potential for a material impact to a company.
    2017 SEC movement toward reportung all cyber risks, regardless of internally determined “materiality”:

  3. A comment on the NTSB as an exemplar:

    We learn and leverage a lot from each aircraft incident, in part because there is a lot of documentation of the design and testing of airframe and power plants, as well as, extensive consideration of normalized “black box” instrumentation..

    1) Traditionally, there has been far less coherent documentation around the “as designed”, testing and “as built” information on IT environments. Even getting accurate asset inventories is very often a challenge.
    2) Conventional security solution deployment and operation has been far more variable, than blackbox instrumentation of aircraft. Moreover, integrations across the multiple security solutions in every enterprise are even less consistent across the various organizations. The resulting signals captured across an incident lifecycle have been difficult to directly compare, at a granular level.

    I believe that as workloads increasingly leverage common platforms, instrumented at comparable levels of granularity, a new and more realizable opportunity to establish an effective cyber incident “NTSB” emerges, addressing these sorts of legacy comparability and instrumentation challenges.

Comments are closed.