WG_Meeting 2022 03 22

SSE Working Group: 2022-03-22

Agenda

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

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)

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?

Action Items