[Smart] CLESS side meeting notes

["Arnaud.Taddei.IETF" <[e-mail]>]

Dear all find below the notes consolidated during the CLESS side meeting.
My thanks to Kirsty for being my scribe on my French-Swiss computer keyboard
As well, I clearly do not masterise Github and I promise to improve myself here but, being in holidays in 2 days, this is not going to happen now.

I sincerely hope this helps

The side meeting happened as scheduled in Coller on Thursday 25th from 4pm until 5:20pm and was attended by 12 persons
To help the meeting Arnaud Taddei prepared some slides that are already in the system and provide a lot of details regarding the status
https://trac.ietf.org/trac/ietf/meeting/attachment/wiki/105side-slides/CLESS-UPDATE-SMART.pptx

The goal of the meeting was to discuss the status of 2 I-D and get feedback from the team on the way forward
https://datatracker.ietf.org/doc/draft-taddei-smart-cless-introduction/
https://datatracker.ietf.org/doc/draft-mcfadden-smart-endpoint-taxonomy-for-cless/

The meeting started with a few reminders that as last year, we got the message from IETF that security can be only done on the endpoints, with nothing in the middle. We went to research on that statement and, believing this was fully codified since 30 years, to our surprise there were research materials but all partial at best with no 360 degree view.

So we realized that it would be good to create an I-D about Capabilities and Limitations of Endpoint Security Solutions (CLESS) from an wholistic perspective and we went on the reminders of its content.

We started with:

- Endpoint models

- The threat landscape for these endpoints

- Endpoint security capabilities: what can I do

- An ideal endpoint security: if we could aim for in a perfect world

- Defence in depth: the notion of not having a single point of failure and having multiple opportunities to prevent an attack

- Limitations of endpoint security: found from research

- Evidence-based examples from production data (others welcome to bring examples from their data)

- Regulatory aspects

- Human rights aspects (still to do)

Yet it revealed that this was quite of a colossal task and it required some organisation of the documents and this is why we considered to split 2 I-Ds, one for endpoint models (the one of Mark McFadden) which goal is to offer a good model of attack surface and one on the threat model which Simon Edwards (chair of AMTSO) agreed to drive. We therefore organized an open call of the 4th of June, we agreed 5 propositions and the second I-D above is in fact the execution on the first proposal to split the endpoint model in a separate I-D. Mark MacFadden volunteered for spearheading this work and started a first version of this new draft.

In other words we want to have the logical construction as per below

Endpoint models / Attack Surface à Mitigation (CLESS) ß Threat Models

Of course this creates a scope re-validation as we understood a few things

Problems to work on: people want it to grow and we don’t want it to scope creep. Maybe CLESS is just a framework, and other specific verticals (iot, mobile, browser, enterprise server) can come and do research on their specific area. It’s goal is not to go to every details but we recognize it should allow other researchers on specific combinations of endpoint, threat models and mitigations to connect their work in the bigger CLESS framework. We recognize it could be a very fruitful approach in the long term. CLESS group of I-Ds is in fact becoming a framework.

How?

For September, well start with phone calls and Google docs. In CLESS, we are looking to work together in a nice way and not with horrible combative atmosphere. Of course robust reviews are good and welcome, but good reviews are not rude or hostile.

What is the plan?

Plan PART 1: Mark McFadden wrote endpoint-taxonomy-cless to describe the endpoints more accurately and give a language for working with these. Reach out to Henk to work on this. Suggestion to make things less qualitative and more quantitative. Due to virtualization and containerization, this varies – IoT characteristic work done elsewhere (David NIST gives reference: RFC 7228). He plans to issue revision in August based on comments from Montreal; and get another version for this before Singapore. Needs to group virtualized environments with their devices, have more detail on the taxonomy. Should it be a taxonomy or a categorization? (How deep to go?)

How can you use it? Given a device, how do I categorise it? (Create some decision tree?) Is software in trusted/untrusted system?

On which level of details to reach? For example this is a real question for the endpoint models: Today the feedback is that the draft is perhaps too simplistic and is more a categorization than a taxonomy. Mark MacFadden of course considered those aspects but how to define which level of details and which aspects to prioritise? Today we are more on qualitative aspects vs quantitative to represent endpoints. Another consideration is that in fact CLESS can be the limiting factor to the race to details. Indeed Arnaud Taddei explained that the criteria could be as simple as looking at the examples that CLESS is calling out and when considering the inferred taxonomy that these examples express, if the endpoint I-D is not offering the taxonomy that means we have a problem either in depth of the taxonomy tree or in width of the taxonomy tree. This echoes a remark from Henk in the SMART side meeting in the morning, hoping Henk can support our Taxonomy approach here

Mark will work on it in August and we will take it from there

Plan PART 2: plan to detach threat landscape (really hard) – section 6 – which is the intention of the attack (do not mix this with the vulnerability that is attacked). This would have to be done per taxonomy class, specific to each taxonomy part. The attack surface is different depending on the endpoint – would include the attack surface and mitigations. This is true - different devices have different capabilities, people assume every endpoint is a browser/laptop or server – not a constrained IoT device that wont be updated, or legacy. So we have to build a language we can talk about to bring in these aspects.

- Which one is best to do first? The traditional endpoint is the easiest but not the most valuable and feeds into the confirmation bias. Highly constrained devices would also be easy-ish. Mobile?

- Mesh-based sensor network, in a car – is the endpoint the tyre pressure monitor or the ECU?

Plan PART 3: Develop the human rights section (Dave McGrew, Cisco / Mallory, Article 19)

- Agreed to develop this together

- Includes regulatory compliance

- German government Bundestroyan (Government Trojan), from such a privacy-focused country

Plan PART 4: include more production data (JJ, Cisco / Dell / McAfee)

- Respecting anonymity

- Make a framework for selection of data

- Agree methodology to select data for homogeneity and reasonable comparison – possible detach in future if it becomes too big?

Plan PART 5: Economics: if you push everything to the endpoint, who pays?

- Security pays. No Im kidding: this is about who pays today and tomorrow, how much will be?

- Cost of securing vs not securing – for which result

Other to develop CLESS generally: feedback to incorporate, develop intrinsic capabilities (Hannes Tschoenfig, ARM - mentioned about chip capability in saag – to follow-up), bring in work from TEEP (from researcher)

Indeed Considerations about constrained devices were expressed and we remember what Hannes (ARM) working on the TEEP working group expressed at the SAAG meeting about all the security that ARM and others put at various levels as intrinsinc security aspects. Arnaud explained that TEEP was important (Ming Pei one of the authors being at Symantec too) and that CLESS recognizes (in the document) that the massive effort that TEEP did to unify the endpoints from both sides of the communication: User Equipments/IoT but as well Hosts from physical to server-less. There is as well another member of TEEP who made an interesting I-D for consideration Faibish Sorin [https://datatracker.ietf.org/doc/draft-faibish-iot-ddos-usecases/](https://clicktime.symantec.com/3LqgQyBz1eQqr6h1MJAx6Nw7Vc?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-faibish-iot-ddos-usecases%2F)

CLESS in IRTF / IETF / should it go outside this community ? Taxonomy could be used in SACM? Wider than SACM. Opportunity to stabilize language across WGs. Could have been used in SACM, TEEP, RATS – perhaps it should be presented at these groups for input.

Conclusion

- Mark will work on his I-D in August

- Symantec will work with DB in August

- Arnaud will organize a call for September and considers the following tasks on top of what is described in the slide deck

- meet with AMTSO at their meeting 31st of Sep, 1st of October and help them start their I-D

- Arnaud and David McGrew will work on the Human Rights section

- start to review SACM, RATS, TEEP and other IETF group that speak about the endpoint

- contact Hannes through Ming

- contact Faibish

- work with Jari Arkko from his I-D and see if there is a chance for an interfacing between the his I-D and the CLESS group of I-Ds

Sent with [ProtonMail](https://protonmail.com) Secure Email.