Author: Sean O’Dell

The December 2024 Gartner IAM CAEP Interop event in Dallas was a huge success with numerous companies showcasing their adoption, continued investment and interest in the Shared Signals Framework. That said, it is time to release this series of blog posts diving deeper into Shared Signals and its applicability in the greater Identity and Access Management (IAM) context, especially now we have just completed our third Shared Signals interop event at Gartner IAM London. This is the first of four posts that expands on Shared Signals, where we are now and our vision for what Shared Signals can deliver. This first blog post will cover the security aspects and advantages of Shared Signals highlighting two event types in real world use cases. The second post will touch on provisioning and the crossover with System for Cross-domain Identity Management (SCIM) events covering real world usage. The third post will provide a cross section of Shared Signals as it applies to both continuous identity and modern IAM along with where Shared Signals will take the industry. Lastly, we will talk about Shared Signals strategically, as a central nervous system for identity and open data systems.

And here…we…go… 

It seems as though every week there are security headlines involving data breaches, hackers gaining access to systems, state-sponsored attacks, insider threats, lack of multifactor authentication (MFA) and so on. Security is top of mind these days and companies are chasing the elusive goal of Zero Trust. They are challenged or blocked by a myriad of complexities, vendor based/solution specific API’s and/or lack of communication between security vendors/products. The lack of preventative measures like MFA combined with an insider threat is compounded by the lack of a communication fabric when those threats are exploited. It always comes back to “needing a way to talk to each other”. Enter Shared Signals Framework (SSF).

What are Shared Signals?

At a high level, shared signals refer to services and security platforms that can seamlessly and securely share information about threats and events, empowering a more coordinated and proactive response. There are many real world comparisons to shared signals such as amber alerts, wireless emergency alerts, neighbors sharing screenshots or videos of suspicious activity, and city or municipal emergency response systems (police, fire and other systems), just to name a few. The key insight is to get the right type of real time alert into the hands of the right target population so that those individuals or systems can take remediating steps immediately. In the digital domain, these alerts start with risk signals associated with accounts and sessions.

Best Practices

“With great power comes great responsibility”. This is a great quote and resonates well with the topic of best practices to fully utilize shared signals. There are varying points of view to consider such as business, contractual, privacy, legal, compliance, operational and technical. Having a 360 degree view about the consumption and use of these signals is important to not overlook. Here are a few examples covering some of the viewpoints above.

Compliance

Shared signals are your best friend here and an enabler for a lot of compliance aspects. Here are some questions it can help address. When was a configuration updated and by whom? When a user or employee was left or was off boarded from the company can you prove that their accounts, access and session were disabled or revoked in a timely manner? When a sensitive or privileged application was accessed can you demonstrate that the proper authentication occurred per policy (e.g. MFA or non-phishable factors like WebAuthN or Passkeys)? Addressing the above questions using open and interoperable standards is a best practice and a way to address compliance complexity. Lastly, a different aspect of compliance with shared signals can be viewed as ensuring the right events were sent to the appropriate systems or receivers with the appropriate data and agreed upon contract. Ensuring this is important to not have data leakage or distributing excessive data to systems or receivers.

Legal / Privacy

While not exhaustive here, the considerations cover both intra-business use of shared signals and business to business (B2B) scenarios. Shared signals is and can be viewed as a trust framework for data and event sharing. That said, it is important to adhere to minimalistic data principles. For example, ensure subject information in the event is just enough to help the receiver or system make a decision and/or take action. A great example of minimalism, and a best practice, is using a non-identifiable identifier, such as a globally unique identifier (GUID) instead of email, username or other personally identifiable information (PII) where a user is the subject of the event. Situations may arise that call for the inclusion of attributes that are identifiable and this is where consulting with legal is a good practice to follow. When integrating with an external company, in a B2B scenario, it is best practice to consult with legal and privacy teams from both companies. When exchanging data between companies it is best practice to obfuscate identifiers and keep it scoped to the relationship between company a and company b. A great example is to use pairwise pseudonymous identifiers (PPIDS) during the event exchange, when the user is the subject of the event.

Use Cases and Examples

Let’s start out with some “CAEPabiliites” with continuous access evaluation: CAEP stands for Continuous Access Evaluation Profile, and involves real-time evaluation of user access and session management that is contextually aware as user conditions and behavior evolve. Examples of CAEP events are “session revoked,” “credential change,” “assurance level change,” or “device compliance changes.” Click here to read more about CAEP.

If only the 80’s movie were titled “RISCy Business”…that would make this pun stick: RISC stands for Risk Incident Sharing and Coordination and focuses more on compromised accounts, especially when they are linked in some way to security incidents. Examples of RISC events are “account enabled,” “account disabled” or “identifier changed.” Click here to read more about RISC.

An Employee Leaves the Company

Session management still is a prevalent problem in the industry and at companies. That said, adopting Shared Signals can help to alleviate this. The classic situation is an employee who is leaving the company and actions need to be taken outside of normal HR event notifications.  While this seems to be pretty cut and dry to a layperson, it does get complicated when you factor in session management across IAM systems, collaboration apps, and (often) multiple identity providers. Using both CAEP and RISC events here can help to address this in a standards based way that allows for coordinated response to an employee’s departure at scale across a company by using a session revoked event (CAEP) coupled with an account disabled event (RISC). There is an added benefit here if companies also operate within one or more “federations” to one or more other companies. RISC events using the Shared Signals Framework as the communication protocol mechanism exist to facilitate this type of enhanced security collaboration between cooperating parties in a bilateral or multilateral federation, or trust framework. In this example, when the employee leaves the company, the same account disabled event (RISC) would be sent to both the company and the other companies so that all relevant parties can perform the proper security functions at the same time, in real-time(i.e. “disable federated accounts,” “disable linked accounts,” and “remove access”). It is also important to note in the picture below that these events should be logged to the Security Information and Event Management (SIEM) for all parties participating in the coordinated response, as indicated by the green circle and checkbox.

Suspicious Activity on User Accounts

This use case is an interesting one and very context based, and in some cases subjective. To highlight how you could use Shared Signals for this we are going to break this down into 2 potential options. Before we get into that it is important to talk about subjects within Shared Signals. Subjects are important as they are the primary focus of security events within the Shared Signals Framework, which consist of users, devices, or groups of users, to name a few. To learn more about subjects click here.  

Progressive Approach

There will need to be some assumptions made here before we dive into the Shared Signals part. 

Assumption 1: The SIEM or Identity Threat Detection and Response (ITDR) platforms can classify behavior at the device level and associate that to a user. Assumption 2: Sessions are tracked and managed by either the Identity Provider or select high impact or sensitive systems in the organization.

Given the assumptions above, an organization's security posture can be hardened while not impacting the end user’s experience, using the Shared Signals Framework. Crazy right? How can this be so? Here is the situation at hand. There appears to be suspicious activity originating from rogue IP addresses or new devices that have not been classified as normal or having been used by the user previously. We now have a different context level to target for revocation…device. Session revoke events (CAEP) can be emitted from the Shared Signals Transmitter with different subjects to selected receivers. In one of the session revoke events, the subject will be the IP Addresses or CIDR range, in the other it will be the rogue device identifier. This will allow an organization to target the suspicious entities, by IP addresses and rogue devices, without impacting an end user's experience. These session revoke events would then be sent to the Identity Provider and high impact systems that have configured a stream setup with the transmitter. This is part of what is meant by a progressive approach, as time passes we have more context to draw from…sharing signals. So, time has passed when either the IP addresses or rogue devices suddenly appear again. Now that we know we can target these attributes, we can take another “progressive” action and issue a credential change event (CAEP) because it can be derived that there is an account take over (ATO) occurring.  

Prescriptive Approach

Nothing changes from the assumptions made in the progressive approach except how security will be actioned. The situation is the same as above: “There appears to be suspicious activity originating from rogue IP addresses or new devices that have not been classified as normal or having been used by the user previously.” 

Given that assumption, this will be more drastic and impactful for the end user, but it might be required based on your organization’s security policies. A session revoke event (CAEP), account disabled event (RISC) and even credential change event (RISC) will be emitted to the identity provider and high impact systems for this scenario to ensure the security controls are reactive based on the context of the deviations in user behavior or patterns. 

You might be asking how would the transmitter know the action was taken by the receiving systems and performed successfully? Reconciliation or double entry bookkeeping can be accomplished just by adhering to the “sharing is caring” methodology. Receivers should be transmitters, bottom line. This is where we are going next on this post.

Chaining Together Security Events

Expanding on the examples above, where an employee leaves the company or suspicious activity is detected on a user’s accounts, we can now start discussing action verification, reconciliation, and double entry bookkeeping in regards to security events. This is where Shared Signals shines! In order to get to zero trust we have to find a common way to communicate. The picture below is a great reference to help visualize the reconciliation and chaining aspects of Shared Signals as they are very powerful and useful, as it enables scale across an organization and between organizations in real time. 

Security Event #1: Acme Corp had issued an account disabled event (RISC) to Wonka Industries, a subsidiary of Acme Corp. After Wonka Industries acknowledges the inbound account disabled event (RISC) from ACME Corp internal policy will take action from the inbound event. Once the actions are all successfully performed, an outbound security event will be transmitted back to ACME Corp in the form of another account disabled event (RISC). Here is where the auditing, bookkeeping, and reconciling comes into play. There was a txn claim that was originally sent over in the first account disabled event (RISC) from ACME Corp with a value, let’s say it was “a1b2c3d4e5”. Now, when Wonka Industries replies back to ACME Corp it will also include the txn claim with the same value that was used in the original account disabled event (RISC), “a1b2c3d4e5”. The simplicity of this allows for verification of the security event being actioned by all parties involved, with double entry bookkeeping for auditing purposes. 

Security Event #2: Acme Corp had an account disabled event (RISC) to Initech, a different company. You may have noticed above that the events do match between ACME Corp and Wonka Industries. This begs the question…do the events always have to match for reconciling? No. The same concepts and principles apply here, as they did in scenario 1, with a minor difference. When Initech received the inbound account disabled event (RISC) from ACME Corp they chose to reply with a session revoked event (CAEP). Why is this? It could be numerous things: policy, their CAEPability mappings, or Initech just revoked sessions for the federated identities that were just-in-time provisioned for access from ACME Corp. That said, the same txn claim that was used, “a1b2c3d4e5”, by ACME Corp will be sent back by Initiech to essentially “close the loop”. Regardless of what policy is selected by the two connected entities or the federation of interconnected entities, all participants are following the same practice of exchanging account disabled events or session revoked events and all entities will maintain accurate data.

The future is upon us now where standards foster cooperation and a “sharing is caring” mentality, such as the Shared Signals Framework (SSF) along with event types like Continuous Access Evaluation Profile (CAEP), Risk Incident Sharing and Coordination (RISC), and soon, SCIM Events. Many relying party implementers may feel most comfortable starting as a recipient of RISC and CAEP events, but the crucial jump is actually to establish the trust required to exchange events both ways. The two-way exchange of signals is what will ultimately deliver on the long term strategy of public and private sector interconnected ecosystems, which we will get to in parts 3 and 4.

For now, tune in next time for part 2…”Yes, Provisioning can be easier with Shared Signals” and stay safe out there.

About the OpenID Foundation

The OpenID Foundation (OIDF) is a global open standards body committed to helping people assert their identity wherever they choose. Founded in 2007, we are a community of technical experts leading the creation of open identity standards that are secure, interoperable, and privacy preserving. The Foundation’s OpenID Connect standard is now used by billions of people across millions of applications. In the last five years, the Financial Grade API has become the standard of choice for Open Banking and Open Data implementations, allowing people to access and share data across entities. Today, the OpenID Foundation’s standards are the connective tissue to enable people to assert their identity and access their data at scale, the scale of the internet, enabling “networks of networks” to interoperate globally. Individuals, companies, governments and non-profits are encouraged to join or participate. Find out more at openid.net.