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

[Kathleen Moriarty <[e-mail]>]

+1

Sent from my iPhone

> On May 22, 2014, at 9:03 AM, "Takeshi Takahashi" <[e-mail]> wrote:
> 
> Hi Eric and Martin,
> 
> Thank you for your kind comment.
> We will keep in mind that we should avoid having two things that do the same
> thing.
> 
> In my humble opinion, the CPS draft hands issues that are outside the scope
> of the SCI draft.
> I think the next version of the CPS draft will sort out lots of this type of
> questions.
> 
> Kind wishes,
> Take
> 
> 
>> -----Original Message-----
>> From: mile [mailto:[e-mail]] On Behalf Of Eric Burger
>> Sent: Thursday, May 22, 2014 4:56 AM
>> To: [e-mail]
>> Subject: Re: [mile] New Version Notification for
>> draft-murillo-mile-cps-00.txt
>> 
>> And I do not think the world is eager to have two things that do the same
>> thing. We already have that problem in this space. I would suggest
> adopting
>> one and only one way of doing this. I have no opinion as to whether it
> should
>> be CPS or SCI.
>> 
>> On May 9, 2014, at 7:17 AM, Takeshi Takahashi
>> <[e-mail]> wrote:
>> 
>>> Hi Martin,
>>> 
>>> Thank you for your kind comments.
>>> 
>>>> There's one question that still lingers: whether we should not
>>>> re-utilize other extensions or use the IODEF-extension for structured
>>>> cybersecurity (draft-ietf-mile-sci-11.txt). Ideas? I believe the
>>>> points above would be applicable to both scenarios.
>>> 
>>> I like this CPS draft, but I also like IODEF-SCI's framework (well, I
>>> am one of the authors).
>>> I do not want to be the obstacle of developing this interesting work,
>>> so I do not have any intention to stick to IODEF-SCI at all.
>>> But I would like to understand the pros and cons of not using SCI
>>> framework for the CPS extension more vividly.
>>> 
>>> Section 1.7 of the CPS draft explains the reason for not using the
>>> IODEF-SCI's framework, but it was not so clear to me..
>>> Can we discuss this issue when we have got example XML documents of
>>> the CPS extension? (I guess later version of the CPS draft will have
>>> the example XML
>>> documents?) Then we can compare how the XML documents will look like
>>> for each case of using and not using IODEF-SCI framework on the CPS
>> extension.
>>> 
>>> Kind regards,
>>> Take
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Martin Murillo [mailto:[e-mail]]
>>>> Sent: Wednesday, April 30, 2014 12:30 PM
>>>> To: Takeshi Takahashi; [e-mail]
>>>> Subject: Re: [mile] Fwd: New Version Notification for
>>>> draft-murillo-mile-cps-00.txt
>>>> 
>>>> Dear Takeshi,
>>>> 
>>>> Thanks for the feedback and highlighting various extraneous elements
>>>> which have rich IODEF equivalents. This makes the reporting lighter
>>>> and decreases implementation overhead. I have answered to each item
>> below.
>>>> 
>>>> 1. The IncidentType element specifies whether the incident is
>>>> accidental, on purpose, or theresult of other actions. The IncdntType
>>>> attribute is missplaced. Thanks for taking notice of that. However I
>>>> wonder whether the IncidentType element should be renamed. I think we
>>>> agree that we need a field where whether the incident is accidental,
>>>> on purpose, or undetermined can be placed. While the nature of the
>>>> incident is rarely known immediately, there are instances in which
>>>> the operator or other local party causes accidental instances; these
>>>> instances might cause repercussions in other locations (i.e.
>>>> balancing in
>>> an electric grid).
>>>> 
>>>> 2. I agree with you, the IncidentTilte element is a perfect candidate
>>>> to go to a shallower level, especially when it will be the first
>>>> variable that an operator or appropriate party reads.
>>>> 
>>>> 3. Given that the IODEF:Contact class is rich enough to differentiate
>>>> between a reporting party and an additional contact
>>>> person/institution, I believe that we should use such class. Because
>>>> the different stakeholders responsible for the Corporate Network,
>>>> Control Servers, and Field Devices, this class might need to be
>>>> extended. This is also relevant when the attack has taken place at
>>>> any of those levels: For instance, the Corporate Network (or a false
>>>> impersonator) might instruct the control room (Control servers) wrong
>>>> setpoint configurations. Or the Control Network might experience a
>>>> breach and setpoints altered in such servers. In extreme situations,
>>>> the
>>> attacks might be directly to the field devices. In each of those cases.
>>>> In each of those cases the contact person might be one or more.
>>>> 
>>>> 4, 5, 6. I think the IODEF classes can be indeed used. Thank you. The
>>>> extension capabilities fo the System Class makes it quite appropriate
>>>> to offer rich information.
>>>> 
>>>> Regarding your last point, SFK should indeed be used instead of SFC.
>>>> 
>>>> There's one question that still lingers: whether we should not
>>>> re-utilize other extensions or use the IODEF-extension for structured
>>>> cybersecurity (draft-ietf-mile-sci-11.txt). Ideas? I believe the
>>>> points above would be applicable to both scenarios.
>>>> 
>>>> Martin
>>>> 
>>>>> On 4/23/2014 4:42 AM, Takeshi Takahashi wrote:
>>>>> 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%20
>>>>>> C
>>>>>>> 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/Con
>>>>>> t
>>>>>>> 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
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> mile mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/mile
>>>>>>> _______________________________________________
>>>>>>> mile mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/mile
>>>>>> _______________________________________________
>>>>>> mile mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mile
>>> 
>>> _______________________________________________
>>> mile mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mile
> 
> 
> _______________________________________________
> mile mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mile