Re: [mile] Fwd: New Version Notification for draft-murillo-mile-cps-00.txt

[Martin Murillo <[e-mail]>]

Have read the links posted by Jerome and info on the Experience Sharing 
Tool (EST). It is my impression that a revision under the light of the 
EST would be very appropriate, and one of the first uses of the 
extension, given its report-based nature.  Look forward to seeing the 
reviews in this light.

As Jerome mentioned, focusing on referencing already existing taxonomies 
(and when necessary reusing them and referencing their xml 
implementations, if publicly available) would be the best approach; 
given the early stages in the field, I tend to think that atomic data 
will need to be used.

Regarding the term "Asset" vs "System", I believe system provides a more 
general connotation, while asset, seem to focus more on mainstream 
infrastructure; because the inclusion of IoT-related infrastructure 
(anywhere from centralized home control to self-driving cars), I wonder 
whether "Asset" is too an specific term.

Martin

Martin

On 1/24/2014 2:09 PM, Johnson, Blake wrote:
> This is an interesting application of IODEF that I had not considered. Most industry sharing that takes place in this space, from my perspective, is in the form of in person and telephone threat briefings. These are facilitated by the FBI, DHS, and the ISAC's.
>
> At least a handful of the ISAC's have started sharing structured threat indicator data, and the taxonomy for this extension could cover what the Electric Sector ISAC currently refers to as 'Experience Sharing.' I can review this proposal as it relates to information captured by the ES-ISAC's Experience Sharing tool, using IEC/ANSI 62443 (ISA99) as an informative reference.
>
> Blake Johnson
> Threat Intelligence Analyst
> Alliant Energy | Infrastructure Secruity
> Office: 608-458-6320 | Cell: 608-843-2790
>
>
> -----Original Message-----
> From: mile [mailto:[e-mail]] On Behalf Of Jerome Athias
> Sent: Friday, January 24, 2014 3:18 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [mile] Fwd: New Version Notification for draft-murillo-mile-cps-00.txt
>
> Hi,
>
> from what I know (which is limited), and as you mention, this ICS area
> is often also called Critical Infrastructures (CIs), or SCADA
>
> for a little bit of background, we could explore the Cybersecurity Framework
> Example references
> http://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx
> http://www.ictqatar.qa/en/documents/download/National%20Industrial%20Control%20Systems%20Security%20Standard-English.pdf
> ANSI/ISA-99.02.01-2009
>
> I don't have enough knowledge about the status and adoption of the
> different efforts in term of XML representation/format/standards
> http://xml.coverpages.org/emergencyManagement.html
> and resilience
>
> It would maybe be possible to obtain information from there
> http://ics-cert.us-cert.gov
> http://ics-isac.org/
>
> My first feedback is that it looks like an interesting extension.
>
> I would suggest to focus on the reuse of existing Taxonomies, or
> references to them.
>
> As such, for [Industry], maybe
> http://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2012
> ISO 3166 (Country Codes)
>
>
> [TargetSystems], I (personally) don't like the word "system" and prefer "asset"
>
> [CompromisedPhysicalInfrastrucute] (with a typo ;p) seems to be a
> category of "Infrastructure" (or group of assets)
>
>
> [EntryPoint] could be ok since it could be a little bit different from
> "endpoint"
>
> [PerpetratingParty] seems to reference "Threat Actor" or "Threat
> Agent" or "Attacker"
>
> [RecurrencePreventionMeasures] is this Security Controls? (and
> Mitigations/Remediations)
> Reference: https://web.nvd.nist.gov/view/800-53/control?controlName=AC-3&type=1
>
>
> Describing an [Exploit] is not so easy (depending on the level of
> details wanted/needed)
>
> Figure 1 (or "Diagram 1") is interesting, (of course it is different
> from, i.e. CAESARS), it MAYBE could be more layered
> http://www.isa.org/InTechTemplate.cfm?template=/ContentManagement/ContentDisplay.cfm&ContentID=94401
>
> (To follow: ENISA CDXI)
>
>
> Some typos
>
>
>
> Next step: more XML focused ;)
>
>
> My 2 bitcents
>
> 2014/1/24 Martin Murillo <[e-mail]>:
>> Dear all,
>>
>> Please find below a link to a proposed draft for extending IODEF for the
>> reporting of cyber-physical system incidents. These systems are often
>> referred as  Operational Technology Systems, Industrial Control Systems,
>> Automatic Control  Systems, or simply Control Systems.
>>
>> Cyber-Physical systems have been around for decades.  However, they are now
>> at a higher risk to be  the target of attacks by individual highly-skilled
>> attackers, organized groups, nation-states, or simply suffer repercussions
>> of mainstream IT cyber-attacks. While over 90% of critical control system
>> infrastructure is currently owned by private enterprises, these can have
>> direct repercussions on national security of world nations.  Indeed, various
>> of these systems are key parts of nuclear reactor facilities, transportation
>> systems, electric power distribution, oil and natural gas distribution,
>> health care, water and waste-water treatment, dam infrastructure, missile
>> and defense systems, and others.   The disruption of these control systems
>> could have a significant impact on public health, safety, and lead to large
>> economic losses.
>>
>> Among the issues that catalyze this higher risk are:
>>
>> i) these systems are gradually becoming more interconnected, ii) legacy
>> systems do not have proper cybersecurity protection, iii) the existence of
>> highly-skilled individuals and motivations, iv) some these systems are
>> generally considered critical, v) these are a natural extension of IT
>> cyber-attacks, vi) the emergence of the Internet of Things (IOT), and vi)
>> these attacks can be carried out remotely and quite inexpensively.
>>
>> While there might exist national approaches to deal with incidents, there's
>> the need of a global international approach that will engulf governments,
>> private organizations and other stakeholders. IETF, as a leading global
>> Internet standards organization, seeks to satisfy this need through open
>> standards that seek to encompass issues that are critical for the global
>> community.
>>
>> Feedback at two levels are welcome:
>>
>> 1. On the existence and inclusion either by utilizing any already existing
>> industry formats (XML-   encoded) and/or by utilizing atomic data
>> 2. Contributions on making the extension (and background information) more
>> comprehensive, accurate and principally useful for the community
>>
>> Look forward to feedback and other input!
>>
>> Martin Murillo
>>
>> A new version of I-D, draft-murillo-mile-cps-00.txt
>> has been successfully submitted by Martin Murillo and posted to the
>> IETF repository.
>>
>> Name:           draft-murillo-mile-cps
>> Revision:       00
>> Title:          IODEF extension for Reporting Cyber-Physical System
>> Incidents
>> Document date:  2014-01-21
>> Group:          Individual Submission
>> Pages:          24
>> URL:
>> http://www.ietf.org/internet-drafts/draft-murillo-mile-cps-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-murillo-mile-cps/
>> Htmlized:       http://tools.ietf.org/html/draft-murillo-mile-cps-00
>>
>>
>> Abstract:
>>     This draft document will extend the Incident Object Description
>>     Exchange Format (IODEF) defined in [RFC5070] to support the reporting
>>     of incidents dealing with attacks to physical infrastructure through
>>     the utilization of IT means as a vehicle or as a tool.  These systems
>>     might also be referred as Cyber-Physical Systems (CPS), Operational
>>     Technology Systems, Industrial Control Systems, Automatic Control
>>     Systems, or simply Control Systems.  These names are used
>>     interchangeably in this document.  In this context, an incident is
>>     generally the result of a cybersecurity issue whose main goal is to
>>     affect the operation of a CPS.  It is considered that any
>>     unauthorized alteration of the operation is always malign.  This
>>     extension will provide the capability of embedding structured
>>     information, such as identifier- and XML-based information.  In its
>>     current state, this document provides important considerations for
>>     further work in implementing Cyber-Physical System incident reports,
>>     either by utilizing any already existing industry formats (XML-
>>     encoded) and/or by utilizing atomic data.
>>
>>     In addition, this document should provide appropriate material for
>>     helping making due considerations in making an appropriate decision
>>     on how a CPS reporting is done: 1) through a data format extension to
>>     the Incident Object Description Exchange Format [RFC5070], 2) forming
>>     part of an already existing IODEF-extension for structured
>>     cybersecurity information (currently draft
>>     draft-ietf-mile-sci-11.txt), or others.  While the format and
>>     contents of the present document fit more the earlier option, these
>>     can also be incorporated to the later.
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>>
>>
>> _______________________________________________
>> mile mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mile
> _______________________________________________
> mile mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mile
>
>