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

"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Fri, 09 May 2014 11:17 UTC

Return-Path: <takeshi_takahashi@nict.go.jp>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F801A0282 for <mile@ietfa.amsl.com>; Fri, 9 May 2014 04:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.857
X-Spam-Level: ***
X-Spam-Status: No, score=3.857 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7o7W5NjjNJHj for <mile@ietfa.amsl.com>; Fri, 9 May 2014 04:17:27 -0700 (PDT)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 586F01A0277 for <mile@ietf.org>; Fri, 9 May 2014 04:17:27 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id s49BHMA8001752 for <mile@ietf.org>; Fri, 9 May 2014 20:17:22 +0900 (JST)
Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id s49BHMge013215 for <mile@ietf.org>; Fri, 9 May 2014 20:17:22 +0900 (JST)
Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id E7E351664B for <mile@ietf.org>; Fri, 9 May 2014 20:17:21 +0900 (JST)
Received: from VAIO (unknown [133.243.119.184]) by mail3.nict.go.jp (NICT Mail) with ESMTP id DF7F516649 for <mile@ietf.org>; Fri, 9 May 2014 20:17:21 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: mile@ietf.org
Date: Fri, 09 May 2014 20:17:26 +0900
Message-ID: <000001cf6b78$42243370$c66c9a50$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac9reC5fiwDq2RjISkSLThbiXH9Rfw==
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.97.8 at zenith2
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/mile/ejyFPgKE39ParFbOCIJkrLp_OV4
Subject: Re: [mile] Fwd: New Version Notification for draft-murillo-mile-cps-00.txt
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 11:17:30 -0000

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:murillo@ieee.org]
> Sent: Wednesday, April 30, 2014 12:30 PM
> To: Takeshi Takahashi; mile@ietf.org
> 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:mile-bounces@ietf.org] On Behalf Of Martin 
> >> Murillo
> >> Sent: Wednesday, January 29, 2014 10:11 AM
> >> To: Johnson, Blake; Jerome Athias
> >> Cc: mile@ietf.org
> >> 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:mile-bounces@ietf.org] On Behalf Of Jerome 
> >>> Athias
> >>> Sent: Friday, January 24, 2014 3:18 AM
> >>> To: murillo@ieee.org
> >>> Cc: mile@ietf.org
> >>> 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 <murillo@ieee.org>:
> >>>> 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
> >>>> mile@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/mile
> >>> _______________________________________________
> >>> mile mailing list
> >>> mile@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/mile
> >>>
> >>>
> >> _______________________________________________
> >> mile mailing list
> >> mile@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mile
> >
> >