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

[Eric Burger <[e-mail]>]

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