[Openid-specs-risc] Call notes

[Martin Gallo]

Hello everyone,
I left some specific comments and suggestions in the shared document, but wanted to share more general feedback regarding this discussion, a very good and important one in my opinion.


  *   Besides the challenges and problems mentioned in the document, I think it’s important to consider the availability, quality and primarily trustworthiness of the data to be shared. The following are some recent papers/reports that illustrate some of this challenges: [1] [2].
     *   What are the right incentives for sharing identity-related threat information, and how to apply those across the ecosystem? How to establish trust between parties? What are the privacy, security and adversary considerations that need to be taken care of? What are the mechanism to classify the data, and honor/enforce that classification?
  *   One of the more important items I guess would be to define at what level do we think SSE can have a play when it comes to share data.
     *   Do we want to use SSE to exchange Threat Information or machine-readable Threat Intelligence? Do we want to use SSE to exchange events and signals, or other type of information as well?
  *   I’d guess that following that, we’ll need to identify and expand on a couple of use cases that we think are of interest, and where using SSE might make more sense to apply than the current standards.
     *   What’s the added value? What can be done with SSE that’s currently not possible or less efficient/convenient/effective with other standards?
  *   I made a first try at adding some potential reasons not to propose the use of SSE, as discussed during the meeting.
  *   The cybersecurity space already has a couple of well-established standards for exchanging threat information and threat intelligence. Some of those are STIX and TAXII, OpenOIC, etc. I’ve added a brief overview matrix of some of the main standards/specs currently in use for sharing threat information, feel free to add any missing one or any feedback.

An interesting thought exercise might be exploring a very simple “threat event”, breaking it down on the different steps/phases and trying to identify the information that can be potentially exchanged. I’m just making up an example that can be find attached, happy to move it to another format or as a new section in the shared document if you prefer.
Where do you see SSE potentially contributing?

Bests,
Martín.


[1] Is Sharing Caring? A report on current cyber threat intelligence networking practices, results, and attitudes<https://blog.pulsedive.com/cti-networking-report/>
[2] Helping hands: Measuring the impact of a large threat intelligence sharing community<https://www.usenix.org/conference/usenixsecurity22/presentation/bouwman>

From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> On Behalf Of Atul Tulshibagwale via Openid-specs-risc
Sent: Tuesday, March 15, 2022 3:14 PM
To: Openid-specs-risc <openid-specs-risc at lists.openid.net>
Subject: [Openid-specs-risc] Call notes

Hi all,
Here are the notes of the out-of-turn WG meeting that focused on exploring whether it makes sense for the SSE Framework to be used in cybersecurity applications. The notes are also stored here<https://github.com/openid/sse/wiki/WG_Meeting-2022-03-15>.

Out-of-turn meeting for Cybersecurity applications
Attendees

  *   Atul Tulshibagwale (SGNL)
  *   Stefan Duernberger (Cisco)
  *   Jason Garbis (Appgate)
  *   Tim Cappalli (Microsoft)
  *   Nancy Cam Winget (Cisco)
  *   Martin Gallo (SecureAuth)
  *   Tom Sato (VeriClouds)
  *   Lee Tschetter (Okta)
  *   Gail Hodges (OpenID Foundation)

Agenda

  *   Review Sharing Cybersecurity Signals<https://docs.google.com/document/d/1tmMqiXNB-lW9HXIzrivOvaFSts23zAzKLWPcSD740kE/edit?usp=sharing> doc

Notes

  *   Wasn't SSE always meant to be for Cybersecurity? What is specifically being proposed here? Is it an effort to broaden the scope of SSE? Is this a means of sharing intelligence? Perhaps before getting into the details, we should discuss the goals. There are a lot of efforts in terms of trying to share data, so how is this different?

     *   There could be more applications of the SSE Framework than offered by CAEP and RISC, so there could be other types of "profiles"
     *   Some text in the doc highlights that there is the SSE Framework, which could be used in different ways
     *   Cybersecurity is a very broad area
     *   We are trying to bridge existing efforts in the IETF
     *   Alternative take: Can SSE do this? Yes. But should we? For example, Subject Identifiers are in the core SSE spec, and we end up "blowing up" the core spec
     *   It could be much much deeper than just adding a profile
     *   Since we are still struggling to get adoption, so we should not distract from that
     *   A value that SSE provides is that it is a standard for sharing signals, but specific to account, identity and session information
     *   The specific identity-centric use cases of SSE is appealing to some companies (such as SecureAuth)
     *   If we broaden the scope too much, we might lose the value that SSE brings to tackling the specific identity / account / session problems.
     *   We should make sure we do not put too broad requirements on the SSE Framework in order to support new applications such as cybersecurity

  *   We should add a section that gives reason why we should not do this
  *   If we can arrive at a structural role that is not fulfilled today, only then we should proceed
  *   We should address the question: "Why is SSE special?" and only then move forward
  *   The biggest contribution that the SSE WG can do is bring the RISC draft into the OpenID foundation
  *   We should try to arrive at a matrix that differentiates SSE and existing efforts (e.g. TAXII)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20220321/2c974bb2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SSE Example Threat Scenario.md
Type: application/octet-stream
Size: 3427 bytes
Desc: SSE Example Threat Scenario.md
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20220321/2c974bb2/attachment-0001.obj>