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

[Alexey Melnikov <[e-mail]>]

Takeshi has troubles posting to the mailing list, so he asked to forward 
his email.

-------- Original Message --------

> -----Original Message-----
> From: Takeshi Takahashi [mailto:[e-mail]]
> Sent: Wednesday, April 23, 2014 2:29 PM
> To: [e-mail]; '[e-mail]'
> Subject: RE: [mile] Fwd: New Version Notification for
> draft-murillo-mile-cps-00.txt
>
> Hi Martin,
>
> I've read through the drafts. Thank you very much for sharing your
expertise
> here.
> It was a new use case for me, and was really interesting.
>
> I am wondering if we can minimize the number of extension fields by using
> the existing IODEF fields.
> By minimizing the number of similar fields, I hope we can simplify the
draft
> and minimize the burden of implementations.
>
> From this viewpoint, let me ask several checking questions.
>
> 1. IncidentType element and IncdntType Attribute
>    What are the difference between them? I think your current draft has
> them as place holders. I would like to hear a bit further.
>
> 2. The IncidentTitle element
>    Can we use the Description element inside the IODEF:Incident class for
> this purpose, instead of having new field here?
>    It would be useful to have title or such information that can hint the
> content of the IODEF document, but I feel like that it would be helpful
> to have this type of information at the shallower level of IODEF document
> rather than having it in the deeper level of IODEF document (inside
> additionalData)
>
> 3. The ReportingParty element
>    Can we use the IODEF:contact class instead of having new field? We
could
> extend it further if needed.
>
> 4. The ReportReliability element
>    Can we use the IODEF:confidence class instead of having new field? We
> could extend it further if needed.
>
> 5. The TargetSystems element
>    Can we extend the IODEF:system class instead of having new field? We
> could extend it further if needed.
>
> 6. type attribute of the IODEF:Impact class
>    When we use this extension, what value should be set for the type
> attribute of the IODEF:Impact class?
>
> By the way, here are small questions.
>
> 1. should [SFC] be [SFK], since the acronym seems to come from the
initials
> of the authors of the reference (Stouffer, K., Falco, J., and K. Scarfonw)
?
>
> I might have misunderstood your draft, so please correct me if I am wrong.
>
> Kind regards,
> Take
>
>
> > -----Original Message-----
> > From: mile [mailto:[e-mail]] On Behalf Of Martin Murillo
> > Sent: Wednesday, January 29, 2014 10:11 AM
> > To: Johnson, Blake; Jerome Athias
> > Cc: [e-mail]
> > Subject: Re: [mile] Fwd: New Version Notification for
> > draft-murillo-mile-cps-00.txt
> >
> > 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%20C
> > > ontrol%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/Cont
> > > entDisplay.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