Skip to main content
Scidmark

Project SCIDMARK

Created in late 2015, Project SCIDMARK (SCADA Incident Database MARKup) will provide useful information to the general public for review of control systems and embedded device outages.

Objective

The objective of the project was to provide a useful, meaningful, and substantiative database for general availability. As such, the premise of this project was to:

  • Provide substantiative, quantifiable, and (most importantly) attestable information pertaining to control systems outages, events, incidents, and/or accidents;
  • Provide information obtained publicly, freely, and openly, with no proprietary, confidential, or classified information;
  • Provide useful and accessible URLs;
  • Provide a useful tool that is available publicly, freely, and openly available for the general public, or may be utilized by any interest group(s), public and/or private sector allowed; and,
  • Provide the database COMPLETELY FREE OF CHARGE.

Reasons for the Database

One of the most significant reasons for creating such a database is that:

  • There are very few publicly, freely, and openly available event, incident, and/or accident database that exists on/throughout the Internet;
  • Databases that are proprietary either require subscription ($$$), or are privately available only for sector or industry-specific special interest groups (such as E-ISAC);
  • Databases that do exist are limited in the amount of data contained, partially for legal and/or regulatory reasons, partially for limitation of scope of ‘how far down the rabbit hole they want to go’; and,
  • Databases that are available publicly have either been closed down, or have not been actively maintained.

Example: RISI Database

The most recently discussed database within and throughout the ICS/SCADA/control systems cybersecurity community is the Repository of Industrial Security Incidents (RISI). However, it has not been updated since 28-Jan-2015. Here is some background information about RISI:

  • Formerly known as the “Industrial Security Incidents Database” (ISID);
  • ISID was incepted circa 2001 by Byres, Lowe, and Leversage;
  • ISID began at the British Columbia Institute of Technology (BCIT), and was discontinued some time in 2006;
  • ISID was resurrected by Eric Byres and Mark Fabro circa 2008;
  • Byres Research was acquired by ‘exida’ in 2009; and,
  • The Security Incidents Organization (SIO) was incepted circa 2014.

The most positive aspect of the RISI database is that it is publicly and freely available.

The website may be found at risidata.com.

If you review any specific case outages, it provides a little bit more detailed information regarding event or incident. For example, the image (shown below) represents the pipeline rupture (containing refined gasoline) that had occurred in 1999, located near Olympic, WA. There were 3 people reported dead, with 8 additional injureies added, and an estimated $45M in total damages.

So why does RISI only show minimal data within 7 identified fields? Much of that information is contained within the Description, Impact and Action Description fields. How much of the information contained within this framed page from their web site can be used for any level of attestation? Is this substantiative? Perhaps.

The full detailed description of the incident may be found here:
Olympic Pipeline Rupture and Subsequent Fire [RISI Version].

Example: NTSB Database

Another incident database is the publicly available one, hosted by the National Transportation Safety Board (NTSB). Not only is their page layout substantially different, but they split the Executive Summary from the rest of the detailed information.

Clearly, there are more fields identified, which makes it more useful especially if you were investigating the incident for historical purposes. In addition to more detailed information, there are source documents for further referencing pertinent to the investigation case. Could this be used for any level of attestation? Yes. Is it substantiative? Yes.

The full detailed description of the incident may be found here:
Olympic Pipeline Rupture and Subsequent Fire [NTSB Version].

Open Source Intelligence (OSINT)

Overall, the purpose is to demonstrate a form of intelligence; SCIDMARK makes use of aggregated data, from multiple sources that are publicly, openly, and freely available - often referred to today as “open source intelligence” (OSINT).

  • No proprietary or confidential information;
  • No legally-privileged or restricted information;
  • No information that would compromise national security; and,
  • No classified (or unverified, leaked[1] classified) information.

[1] Ref: Wikileaks, Public Intelligence, Pastebin, GitHub, Cryptome, Muck Rock, et. al.

Advantages of the Database

There are several benefits for implementing this project:

  • Aggregated data from multiple sources - into one source;
  • No need to search for all of the sources; most of the research is taken from as many sources as possible;
  • Alternative sources for citing in case primary, secondary, tertiary, … et. al sources become unavailable;
  • May include data from one or more webcached sources; and,
  • No need to hunt for relevant, specific information; all relevant information broken down by “families”.

Disadvantages of the Database

However, with positives come negatives, as there are several liabilities for implementing this project:

  • The aggregated source can become a highly visible target for possible terrorists, governments, hackers, etc.;
  • Although this database was created primarily for the ‘good guys’, the ‘bad guys’ would benefit as well;
  • Research information several locations by itself may prove harmless for adversaries; however, combined, this may provide a one-stop ‘grocery store’ for intelligence;
  • Centralized, aggregated information is one place may be construed or considered as a threat to national security, not just the United States, but perhaps governments throughout the World;
  • If the database were considered a threat to national security, it may become a target not only by the ‘bad guys’, but now may become a target by the ‘good guys’ as well; and,
  • If the database were to be contained, it could become sequestered by classifying the database itself; although this may be highly unlikely within the U.S. (however, nothing is static), it may happen elsewhere throughout the World.

Negative Impacts

Though there may be only a handful of negative impact to this project, any one of them or even combined, can have devastating impact(s) to the operational success to this project:

  • Creation of the database is entirely voluntarily; this means data is gathering, categorized, prioritized, and entered as time becomes available;
  • Creation of entries within the database is manual, and would be very time consuming;
  • Creation of relative or pertinent data may casde into an almost endless and vicious cycle of creating more data from existing data (e.g.; data of data of data … often called ‘metadata’); and,
  • The definition of ‘cyber incident’ is nebulous by its very definition, and consists of close to a dozen versions.

Definition - What is a Cyber Incident?

Based on facts that there are close to a dozen variants for the term ‘cyber incident’, to date, all definitions focus - primarily - on informational aspects of how information is transported, stored, and modified by control systems. However, this could not be any further from the truth as control systems are not concerned with information, but operation. To date, here are the definition variants to the term ‘cyber incident’:

  • NIST Cyber Security Framework (CSF) does not define ‘incident’ or ‘cyber incident’;
  • DHS National Cybersecurity Incident Response Plan (NCIRP) defines ‘cyber incident’ as:
    • A cyber incident is defined as an event occurring on or conducted through a computer network that actually or imminently jeopardizes the confidentiality, integrity, or availability of computers, information or communications systems or networks, physical or virtual infrastructure controlled by computers or information systems, or information resident thereon.
  • NIST SP 800-53, Rev. 4, App. B, p. B-9 (based on FIPS 200) defines an ‘incident’ as:
    • An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.
  • NIST IR 7298, Rev. 2, p. 57 defines ‘cyber incident’ as:
    • Actions taken through the use of computer networks that result in an actual or potentially adverse effect on an information system and/or the information residing therein. See Incident.
  • CNSSI No. 4009 defines both ‘cyber incident’ and ‘incident’ as:
    • [‘cyber incident’, p. 22] Actions taken through the use of computer networks that result in an actual or potentially adverse effect on an information system and/or the information residing therein. See incident.
    • [‘incident’, p. 35] An assessed occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system; or the information the system processes, stores, or transmits; or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.
  • FIPS 200 defines ‘incident response’, but does not define the word ‘incident’;
  • NIST IR 7435 mentions ‘incident’, but does not define it;
  • NIST IR 7621 mentions ‘incident’ and ‘malicious code incident’, but does not define either term; and,
  • Contained within NIST IR 7298, Rev. 2, Glossary of Key Information Security Terms, the definition of the word ‘incident’ can be:
    • [‘incident’, p. 90; source: NIST SP 800-61] A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.
    • [‘incident’, p. 91; source FIPS 200 and NIST SP 800-53] An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.
    • [‘incident’, p. 91; source CNSSI-4009] An assessed occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system; or the information the system processes, stores, or transmits; or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.
    • Within this document alone, there are three definitions for the word ‘incident’.

If you are part of a regulated industry, which one do you use?

Currently, the U.S. federal government is focusing their efforts based on the NIST Cyber Security Framework (or “CSF”) document, despite that the terms ‘incident’ and ‘cyber incident’ are used throughout the document, but are not defined, remains to be an area of contention as the U.S. federal government has failed to establish a baseline definition for either term.

Note though that this is in reference to information technology (IT) and/or operational technology (OT), but not control systems. For control systems’ environments, the de facto document of choice by regulators is NIST SP 800-53[2].

[2] NOTE NERC and NRC (through NEI) both reference and include NIST SP 800-53 as part of their cyber security controls, particularly for control systems.

Conclusion

Although, as a community, we are still attempting to define both ‘incident’ and ‘cyber incident’, by introducing SCIDMARK to the communities of interest, this will provide further guidance towards differentiating IT v. OT v. control systems.

As such, the definitions of ‘incident’ and ‘cyber incident’ will be reflected differently between all of these areas of cyber-based systems. Reason for this groundswell effort are that current definitions are either multiply defined, and/or are confusing.

  • Definitions focus on ‘information’ … instead of ‘operation’; with control systems, the primary focus is that the operation is about the operation;
  • Definitions focus on the ‘IT Triad’ - Confidentiality, Integrity, and Availability; and,
  • Definitions DO NOT focus on the 'OT Triad' - Safety, Availability, Integrity, and Confidentiality.

For more information about IT v. OT v. ICS paradigms, please visit: icsmodel.infracritical.com.

infracritical® is introducing a new paradigm - Safety, Reliability, and Performance.

For more information about this suggested paradigm shift, please visit: srpmodel.infracritical.com.