Re: [Panic] notes on Panic Draft

[Jessica Fitzgerald-McKay <[e-mail]>]

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 <[e-mail]>
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 <
> [e-mail]> 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 <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/panic
>>>
>>> _______________________________________________
>> Panic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/panic
>>
>