[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
Notes from today's call are below. They are also stored here
<https://github.com/openid/sse/wiki/WG_Meeting-2022-03-22>.
SSE Working Group: 2022-03-22
<https://github.com/openid/sse/wiki/WG_Meeting-2022-03-22#agenda>Agenda

   - SSE for Cybersecurity - Martin's feedback
   - Explicit Token Revoked event for CAEP?
   - Continue cyber security applications of SSE discussion
   - VeriClouds demo

<https://github.com/openid/sse/wiki/WG_Meeting-2022-03-22#attendees>
Attendees

   - Atul Tulshibagwale (SGNL)
   - Badi Azad (Google)
   - Jason Garbis (AppGate)
   - Martin Gallo (SecureAuth)
   - Stefan Duernberger (Cisco)
   - Gail Hodges (OIDF)
   - Tom Sato (VeriClouds)
   - Mike Virginio (Wayfair)
   - Stan Bounev (VeriClouds)

<https://github.com/openid/sse/wiki/WG_Meeting-2022-03-22#notes>Notes

   -

   Martin's feedback to 'Sharing Cybersecurity Signals'
   - Difference between 'Threat Information' versus 'Threat Intelligence'
      - These are separate concepts. So do we see SSE as a way of sharing
      Threat Information or Threat Intelligence
      - Threat Information is pieces of evidence of events that are
      happening
      - Threat Intelligence is aggregation of Threat Information and the
      analysis of it in order to conclude about the intent, techniques and
      procedures of the threat actor
      - Pulling different types of events or information
      - Every major Threat Intelligence vendor has implementations of STIX
      / TAXII standards
      - Can SSE be used to provide threat information that is specific to
      identity events?
   -

   Trustworthiness of the data to be shared: Data sovereignty is a big
   concern in Europe, something we should think about.
   -

   There are some standards for data classification.
   -

   Ensure that parties data is being shared with are trusted, and there are
   no leaks
   -

   VeriClouds uses SSE to share compromised credential SET. Actual password
   is not shared, but a verifier is shared.
   -

   Authentication and authorization of Transmitter and Receiver are built
   into SSE
   -

   SSE is a communication protocol that doesn't assure the trustworthiness
   of the content of the stream
   -

   The current SSE spec can be used for verifying compromised credentials
   -

   When we use STIX / TAXII, it goes into the dashboards of the Receiver,
   along with a lot of other signals (SIEM, Network monitoring, etc.)
   -

   They need a way to prioritize. If they do not have the compromised
   password, then they cannot determine the importance of the signal received
   from the credential monitoring service
   -

   There is some potential with security companies in order to use the
   'compromised credential' event
   -

   The 'device compliance' is binary and asserted by the Transmitter in
   CAEP. That may not always be the case. E.g. for accessing some data certain
   patch levels are OK, but for others we may need to have a higher patch
   level to the OS of the device being used to access.
   -

   There's an opportunity to use SSE to provide identity-related events.
   -

   We may identify new types of events, but we will know when we talk to
   cyber security companies.
   -

   We need to be cautious to not distract from existing targets of the
   group in order to explore the cyber-security angle
   -

   If it's already in the spec, and just getting other companies to
   potentially use it, that is something we could push forward with
   -

   What is the handoff between SSE and STIX and TAXII? We could address
   this too in the document
   -

   Explore additional use cases that can be covered with SSE - we can add
   this to the hypothesis document
   -

   If some use-cases are lower priority, we can put them in the appendix
   (e.g. those we think are already covered in the cyber security standards)
   -

   VeriClouds demo
   -

   How can SSE be improved to help make a better product?
   - Receiver has to make a CredVerify API call, there is no way to do this
      in the standard today. It would be nice to do this using SSE
      - Can the SSE event have the password verifier in it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20220322/5bd99870/attachment.html>