Re: [Panic] notes on Panic Draft

Jessica Fitzgerald-McKay <jmfmckay@gmail.com> Thu, 27 July 2017 16:49 UTC

Return-Path: <jmfmckay@gmail.com>
X-Original-To: panic@ietfa.amsl.com
Delivered-To: panic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4377F131CFB for <panic@ietfa.amsl.com>; Thu, 27 Jul 2017 09:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ldf0gal4yquY for <panic@ietfa.amsl.com>; Thu, 27 Jul 2017 09:49:33 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057A7131891 for <Panic@ietf.org>; Thu, 27 Jul 2017 09:49:33 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id d29so135852941uai.2 for <Panic@ietf.org>; Thu, 27 Jul 2017 09:49:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v/FaA51FemwE+BIFMno1KBGUItsV5/pKGp9+RvEJRlY=; b=pIvAEfzQlsbJEEbglLIxYkySRmiQDbVgYZCCuvM18MIjr9k10KlabnozxKb6Og22uO 2XKLWr5GCm1dYKPXJalf+uxkx+nEjOO0kVPTmAcG6W3hGPIRtluItonBpLjywdQHxPUL GbtR7wJQTE2jWqoG/7j/Q2y9dAu9V2PkT8UvE3tT0MtmFAMuU6+kjRMfnQkt0kXWAPRL 1hf5vUg9VOHi+xj8+3LY25Iuk79pnYva0mhnzVx3dvRz8SAjwLG1AMVgN525hiaJuco6 jJVa/4bNUEKJ/usEHHjvm1qq/9hNZjjMoGpFSXBjGI0Qi1rNrqwpLhPb3dS9fucEKJw5 I7gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v/FaA51FemwE+BIFMno1KBGUItsV5/pKGp9+RvEJRlY=; b=cyfJqJGZ7+fSl4MaGQ8WdK+JtW0YJLZ3WLbsziRw1i0GMIb1UgE0R52xUH0fEnx55F u4bgM5Dk+BjEPVpIRW3oV+AldiFDOFNXHktNlPXVzG7UkVL0A1RaFL9THKprJ5BC4EuK IrSpSA5yyJGnjFChhD0ldOWQMGH9glQ6apqL/9sGS7fhPp8FgoocyNLrjE2WFnOII3N7 nfYaIpThoKWPpgKMZLf0F3U/va3lHUYeCE0fX1xfcTTlv+NdnjFLwFncvLrDu3SfE5hG 79o7bHoA5gtIqqmTyhIkzAZB9JlYgFxC7G1JZiuSLqxC5zCbIS/Gvfx4iXCWPx1Zxdxi Ep3Q==
X-Gm-Message-State: AIVw112BzcUoC691GXncqHOsSNr9CBiheQqQiSQ0KLml61keujg8ziHe vA5vVRKCOAdS3FtdK3XWBNaU6/warA==
X-Received: by 10.31.61.198 with SMTP id k189mr3153460vka.134.1501174171960; Thu, 27 Jul 2017 09:49:31 -0700 (PDT)
MIME-Version: 1.0
References: <BN1PR05MB309E68BF47317CB858B8B40BAA40@BN1PR05MB309.namprd05.prod.outlook.com> <CAM+R6NUyt+Vk0sXvGJ7+3oga74FywwV32pSRagRnYgDZttPp4Q@mail.gmail.com> <CACknUNXF3sHxj1K9GwZsncjiD7YUUTJy7y+snn5SnQASZj1DOQ@mail.gmail.com>
In-Reply-To: <CACknUNXF3sHxj1K9GwZsncjiD7YUUTJy7y+snn5SnQASZj1DOQ@mail.gmail.com>
From: Jessica Fitzgerald-McKay <jmfmckay@gmail.com>
Date: Thu, 27 Jul 2017 16:49:21 +0000
Message-ID: <CAM+R6NUv7njLV6GR=PCHS-d8Dfo_GnUVtf3B1OBhhse8g8k02w@mail.gmail.com>
To: Adam Montville <adam.w.montville@gmail.com>, Guy Fedorkow <gfedorkow@juniper.net>
Cc: Panic@ietf.org
Content-Type: multipart/alternative; boundary="001a114dac06440cb105554f59ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/panic/88ZEVw4Jxgw-o5VxDyJCslaJ8uk>
Subject: Re: [Panic] notes on Panic Draft
X-BeenThere: panic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Posture Assessment Through Network Information Collection \(panic\)" <panic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/panic>, <mailto:panic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/panic/>
List-Post: <mailto:panic@ietf.org>
List-Help: <mailto:panic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/panic>, <mailto:panic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jul 2017 16:49:35 -0000

Adam et al.,
Yes, there are a lot of places where sacm, panic and mile overlap. If you
haven't read it, check out this (shamelessly self-promoted) article:
https://www.ietfjournal.org/working-group-update-security-automation-and-continuous-monitoring/
It describes my point of view of how these efforts intersect. I'd love
feedback on it.

Thanks,
Jess

On Wed, Jul 26, 2017, 4:55 PM Adam Montville <adam.w.montville@gmail.com>;
wrote:

> Hi everyone.
>
> It's really good to see additional interest in this subject area! I
> encourage you to review the existing ongoing work in the SACM working group
> - specifically the requirements draft (hopefully through IESG soon; see
> [1]), one of the drafts under adoption consideration (Endpoint Compliance
> Profile: draft-haynes-sacm-ecp) [2], and a data model proposal for carrying
> SACM statements (YANG subscribed notifications via SACM Statements:
> draft-birkholz-sacm-yang-content; see [3]).
>
> After a successful hackathon in Prague, we are redoubling our efforts on
> several of the topics with which PANIC appears to be concerned.  While not
> all of the work PANIC may imply should necessarily be done in the SACM
> group, I would suggest that those of us interested in PANIC look toward
> current working group drafts as well as those being considered for adoption
> as potentially viable approaches to the PANIC problem.
>
> Our SACM-related hackathon efforts are mostly documented at [4]. (Note
> that there were two SACM-related efforts, though only one was exclusive to
> SACM.) We have designs for the next hackathon to integrate these two
> related efforts (which may help answer the question about the link between
> posture server and data store), which could look something like the diagram
> at the bottom of that page (also at [5]).
>
> Of course, there may be little-to-no overlap between what SACM has been
> attempting to accomplish and what PANIC would like to ultimately achieve.
>
> Kind regards,
>
> Adam
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/
> [2] https://datatracker.ietf.org/doc/draft-haynes-sacm-ecp/
> [3] https://datatracker.ietf.org/doc/draft-birkholz-sacm-yang-content/
> [4]
> https://github.com/sacmwg/vulnerability-scenario/tree/master/ietf_99_hackathon
>
> [5]
> https://raw.githubusercontent.com/sacmwg/vulnerability-scenario/master/ietf_99_hackathon/graphics/hackathon_deployment_combined.png
>
>
>
> On Wed, Jul 26, 2017 at 1:46 PM Jessica Fitzgerald-McKay <
> jmfmckay@gmail.com>; wrote:
>
>> Thanks for the feedback, Guy. Responses in-line. I have more questions
>> than answers, and I'd like others on the list to weigh in. Looking forward
>> to hearing from everyone.
>>
>>
>> On Fri, Jul 21, 2017 at 5:18 PM, Guy Fedorkow <gfedorkow@juniper.net>;
>> wrote:
>>
>>>
>>>
>>> Hi Dave, Jessica,
>>>
>>>   Thanks for updating the PANIC draft…  I think it’s starting to take
>>> shape!
>>>
>>>
>>>
>>>   It seems that the next step in moving this forward might be to outline
>>> the kind of information we want to retrieve from the endpoints.  I’d assume
>>> you’d want some kind of info to identify the device – manufacturer, serial
>>> number, etc, plus something that shows the software revision of the
>>> relevant modules.  Could that be something like a set of SWID tags?
>>>
>>
>> ​Personally, I would be delighted if software load could be captured in a
>> SWID tag. Failing that, I would like to be able to collect a swid-like set
>> of information from​ the network device. I took a look at NISTIR 8060
>> (which you can read here:
>> http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf) and it looks
>> like-- ignoring data about the tag itself, like tagID, entity information
>> about the tag creator, etc--  required fields for a primary tag are:
>>
>>    - software name and
>>    - software version,
>>
>> which should be easy enough to collect on their own.
>>
>> But, SWID tags offer additional information that could be useful to us.
>> Evidence and payload fields, for instance, can be used to communicate file
>> hashes that comprise the software. Tag signatures could allow us to have
>> move trust in the entity that created the tag (for example, a tag from the
>> software vendor is potentially more trust worthy than one created by a
>> third party). And SWIDs allow us to easily communicate what patches are
>> installed on the product, which is necessary for vulnerability and
>> compliance assessments.
>>
>> All things considered, I'd like to use SWID tags. I would like a sense of
>> how widely implemented they are for network device software and operating
>> systems. Anyone have any insight there?
>>
>>
>>   It might be good to pattern the device information on IEEE 802.1AR.
>>> Using a cryptographic ID might not be a ‘must’, but it’s probably a
>>> desirable option, so making sure it would fit might be helpful.
>>>
>>
>> 802.1ar requires installation ​
>> ​of an IDevID, from which many LDevIDs can be created. I'm happy to geek
>> out on the added security of cryptographic IDs, but, can we talk though the
>> workflow of getting the initial IDevID installed (who would be responsible
>> for that? Do network equipment vendors use IDevIDs today? If not, could the
>> device owner install one without a lot of hassle?)​.
>>
>>
>> Also, secure though 802.1ar is, it often has no relation to any
>> observable device identities on the network. I'm thinking about a behavior
>> monitoring use case here, in which I notice a device behaving in an
>> unexpected manner, and want to investigate it's posture while I figure out
>> what is going on. Is there a way to gather many identities from an network
>> device using netconf/yang?
>>
>>
>>>
>>>   It might be good to add a note saying whether the draft should extend
>>> to virtualized devices, e.g., NFV instances.  I’d assume that it should,
>>> but that might make identity a bit more complicated.
>>>
>>
>> ​In section 3 of the draft, we say "​Virtualized network functions are
>> currently considered in scope". Of course, I worded it that way because I,
>> too, am concerned about whether their inclusion makes our solution overly
>> complicated. Are there any netconf experts that can speak to this concern?
>>
>>>
>>>
>>>   On the topic of scope, I suppose it might be good to say if “Things”,
>>> as in IoT, are in scope or not.  I can’t guess if that has an impact on the
>>> technical spec, but there certainly could be an impact on implied scaling
>>> needs, and it might help remind readers that figuring out what’s running in
>>> the IoT is a getting to be a big problem.
>>>
>>
>> ​Agreed that IoT is a problem. Do many "Things" that compose the Internet
>> of Things implement netconf?​ It's such a broad space, I worry that some
>> "Things" could handle netconf, and others (things like "smart dust", etc.)
>> couldn't handle the added weight.
>>
>>
>>>
>>>   The diagram in the front of the draft shows an interconnect between
>>> Posture Server and Data Store…  seems like there could be some complicated
>>> transactions across that link…  Do you think there’s existing practice that
>>> could be used for this?
>>>
>>
>> ​Sadly, I know of nothing we could easily point to and say "that is the
>> protocol we will use for server-datastore communication". But, what I do
>> not know could fill volumes. Maybe others have ideas where we can start?
>> ​
>>
>>>   The draft also mentions methods that Endpoints can use to find Posture
>>> servers.  I wonder if Zeroconf or some kind of DHCP trick might work for
>>> this?
>>>
>>
>> ​Zeroconf is an option. TCG has some prior art here (
>> https://www.trustedcomputinggroup.org/wp-content/uploads/Server_Discovery_And_Validation_v1_0r19-PUBLIC-REVIEW.pdf).
>> I am happy to consider all viable options.​
>>
>>
>>>
>>>   Finally, in Security Considerations, I wonder if there should be
>>> something about how much we do or don’t trust the endpoint to report its
>>> Information truthfully. The combination of 802.1AR and signed SWID tags
>>> might help with a way to assess the reliability of the information.
>>>
>>
>> ​Agreed, I will add that to the next revision. ​
>>
>>>
>>>
>>>   Great start, let’s try to start breaking down some of the top-level
>>> topics to get to the next level of requirements.
>>>
>>> Thx,
>>>
>>> /guy
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Panic mailing list
>>> Panic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/panic
>>>
>>> _______________________________________________
>> Panic mailing list
>> Panic@ietf.org
>> https://www.ietf.org/mailman/listinfo/panic
>>
>