Got Ya!: Sensors for Identity Management Speciﬁc Security Situational

Awareness

Daniela Pöhn

and Heiner Lüken

University of the Bundeswehr Munich, RI CODE, Neubiberg, Germany

Keywords:

Security Situational Awareness, Cyber Situational Awareness, Security, Identity Management, OAuth.

Abstract:

Security situational awareness refers to identifying, mitigating, and preventing digital cyber threats by gath-

ering information to understand the current situation. With awareness, the basis for decisions is present,

particularly in complex situations. However, while logging can track the successful login into a system, it typ-

ically cannot determine if the login was performed by the user assigned to the account. An account takeover,

for example, by a successful phishing attack, can be used as an entry into an organization’s network. All

identities within an organization are managed in an identity management system. Thereby, these systems are

an interesting goal for malicious actors. Even within identity management systems, it is difﬁcult to differen-

tiate legitimate from malicious actions. We propose a security situational awareness approach speciﬁcally to

identity management. We focus on protocol-speciﬁcs and identity-related sources in a general concept before

providing the example of the protocol OAuth with a proof-of-concept implementation.

1 INTRODUCTION

The supply chain attack on SolarWinds’ Orion plat-

form (Sterle and Bhunia, 2021) showed that iden-

tity and access management are crucial assets. The

malicious actors took over Microsoft Active Direc-

tory (AD) instances and used the Federation Ser-

vices (FS) extension to access other resources. Se-

curity mechanisms such as single sign-on (SSO) can

be used against the target. According to (Peisert et al.,

2021), the attacker mimicked regular Security Asser-

tion Markup Language (SAML) interactions for their

purposes. However, not only malicious actors may

target AD and SAML, but also other identity manage-

ment (IdM)-related protocols, such as Open Autho-

rization (OAuth) and OpenID Connect (OIDC). De-

tecting symptoms of attempts at an early stage may

speed up the incident response process. This is difﬁ-

cult, as malicious activities are similar to regular in-

teractions, and traditional security mechanisms may

fail. However, this is not the only problem in this con-

text. The variety of IdM protocols (Pöhn and Hom-

mel, 2023) makes it even harder. Lastly, as we deal

with digital identities, we must include humans.

One potential way to improve the current situation

is the application of security situational awareness tai-

https://orcid.org/0000-0002-6373-3637

lored to IdM. Security or cyber situational awareness

is an application of situational awareness in the cy-

ber domain to perceive the environment (perception),

understand the current security situation (comprehen-

sion), and project how the situation will evolve (pro-

jection). Security situational awareness should pro-

vide the operators with a decision-making methodol-

ogy in complex and sophisticated systems. Currently,

several aspects in the ﬁeld are being enhanced. Ac-

cording to (Gutzwiller et al., 2020), humans are often

not included, although they represent critical elements

in this context. As shown above, it is also hard to

differentiate legitimate from malicious user actions.

Therefore, current security situational awareness ap-

proaches have to be adapted to identity management

to include digital identities.

Consequently, we use the following research

questions: What is the general outlook of security sit-

uational awareness that comprises identity manage-

ment? What are suitable sensors and other sources for

IdM-speciﬁc security situational awareness? What

are the practical advantages of such an approach?

In order to increase the security of IdM, we pro-

pose (i.) a generic concept of security situational

awareness speciﬁcally for IdM. Related to that, we

focus on (ii.) sensors and other sources, as they are

the ﬁrst step for security situational awareness. We

show (iii.) the advantages of such an approach using

Pöhn, D. and Lüken, H.

Got Ya!: Sensors for Identity Management Speciﬁc Security Situational Awareness.

DOI: 10.5220/0013092900003899

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 11th International Conference on Information Systems Security and Privacy (ICISSP 2025) - Volume 1, pages 141-148

ISBN: 978-989-758-735-1; ISSN: 2184-4356

141

the example of OAuth and discuss the implications.

Therefore, this paper contributes (1) the derivation of

the sensors and other sources related to IdM that are

required for (2) a concept for IdM-speciﬁc security

situational awareness and (3) the concept and proof-

of-concept implementation for OAuth.

The remainder of the paper is as follows: We ex-

plain the background on identity management and

situational awareness (see Section 2) and contrast it

with related work (see Section 3). Section 4 proposes

the generic concept for security situational awareness

for IdM before Section 5 describes the example of

OAuth. We summarize and discuss our approach in

Section 6.

2 BACKGROUND

2.1 Identity Management

IdM comprises identiﬁcation, authentication, autho-

rization, and general management of users. In

cross-organizational contexts, federated protocols

like SAML, OAuth, and OIDC may be operated. As

the identity providers can collect more data about

the users in these protocols, self-sovereign identities

(SSI) are currently introduced. The user has self-

sovereign control over their data in a so-called wallet.

OAuth and OIDC, the authentication protocol on top

of OAuth, may be used in the SSI context by apply-

ing additional protocols, summarized as OpenID for

Veriﬁable Credentials (OpenID Foundation, 2024).

(1) Authorization Request

(3) Authorization Grant

(5) Access Token

Third Party

Application

(Client)

(2) Authorization Grant

User

(4) Access Token

Authorization

Server

Resource

Server

(6) User Attributes

Figure 1: Generic workﬂow of the OAuth protocol.

OAuth 2.0 (Hardt, 2012) is a protocol for autho-

rization, i.e., OAuth permits users to share account

information with third-party services and applications

without providing them the credentials.

In Figure 1, the generic workﬂow is shown. The

third-party applications request authorization from

the resource owner (i.e., user; step 1). The resource

owner subsequently grants authorization (step 2). The

authorization grant is then forwarded to the authoriza-

tion server (step 3) that provides the third-party appli-

cation with an access token (step 4). The access token

is then forwarded to the resource server (step 5) to

grant access (step 6).

OAuth has speciﬁed different protocol ﬂows,

called grants, that enable authorization with varia-

tions of the workﬂow described above. However,

not all ﬂows are securely usable. The most com-

mon OAuth grant types are authorization code, proof

key for code exchange (PKCE), client credentials,

device code, and refresh token. In contrast, im-

plicit ﬂow and resource owner password credentials

grant are insecure. Furthermore, OAuth-speciﬁc at-

tack vectors are known (Fett et al., 2016), including

OAuth access token abuse and theft (Jannett et al.,

2022), cross-site request forgery (Benolli et al., 2021),

path confusion (Innocenti et al., 2023), and generally

misconceptions (Wang et al., 2016). Security best

practices are described in (Lodderstedt et al., 2013).

OAuth 2.1 (Hardt et al., 2024) is an in-progress update

(currently work-in-progress) that consolidates best

practices and established extensions since OAuth 2.0

was published. Related to the grants, the common

variants described above are included in OAuth 2.1.

2.2 Situational Awareness

Situational awareness describes the cognizance of en-

tities in the environment (perception), understanding

their meaning (comprehension), and the projection of

their state in near future (projection) (Endsley, 1988).

Such a situational awareness is especially important

in a military context. According to (Headquarters,

Department of the Army, 2021), “situational under-

standing is the product of applying analysis and judg-

ment to relevant information to determine the rela-

tionships within the situation.” After determining the

baseline, anomalies can be identiﬁed. These obser-

vations and the understanding of the anomalies in

the context (situation assessment) are relevant for the

projection. The three phases can be adapted for the

cyber domain, speaking of security or cyber situa-

tional awareness. This means that security situational

awareness is part of situational awareness which con-

cerns the cyber environment.

According to (Franke and Brynielsson, 2014), dif-

ferent sensors can be applied, including intrusion de-

tection systems (IDSs), external information, and hu-

man intelligence. (Evesti et al., 2017) propose a tax-

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

142

onomy for cybersecurity situational awareness with a

description of the scope, level, viewpoint, and deci-

sion making. Further, the authors divide data gather-

ing into operational (i.e., antivirus, vulnerability scan-

ner, penetration testing, network scanning, password

cracking, ﬁrewall, and IDS) and strategic (i.e., asset

listing, risk identiﬁcation, surveys, incident response

reports, audit ﬁndings, policy review, and news re-

view). This lists however also shows that the data

sources may have to be adapted to the network.

3 RELATED WORK

Various approaches target security situational aware-

ness. (Husák et al., 2020) provide an overview of

security situational awareness and explain contem-

porary challenges. The authors describe the toolset

perspective through a taxonomy with several entries

in the perception phase. Although most of them,

like scans and log ﬁles, are relevant for IdM, other

sensors and sources might be of value in our sce-

nario. Similarly, surveys (Nour et al., 2023; Tian-

ﬁeld, 2016; Zhang et al., 2023) show several sources

that mainly target networks. (Evesti et al., 2017) in-

clude password cracking. (Rodriguez and Okamura,

2019) propose an approach of cyber situational aware-

ness through social media, security news, and blog

data mining, whereas (Legg and Blackman, 2019)

focus on phishing attacks. Other methods to im-

prove the comprehension phase include netﬂow vi-

sualization (Yin et al., 2004) and graph-based ap-

proach (Husák et al., 2023). These may be adapt-

able to IdM. Lastly, (Zurowski et al., 2022) provide

an overview of offensive cyber operation automation

tools that mostly focus on network security and, thus,

might not be suitable for our purpose.

So far, no approach focuses on IdM, although dig-

ital identities and IdMS are the target of various at-

tacks and current measures are not enough. When ap-

plying security situational awareness to IdM, the pro-

tocols and their attack characteristics must be consid-

ered. This is currently different in related work. In

addition, other sensors speciﬁc to IdM, such as pass-

word leaks, data found in online sources, and the fea-

tures used for risk-based authentication, may be in-

cluded to provide a better picture.

4 IDENTITY SECURITY

SITUATIONAL AWARENESS

In this section, we describe the general concept with

its layers, entities, and relations. We identify the lay-

ers of internal identity management, external identity,

threat, and detection. Within these layers, we focus on

sensors and other data sources that can be used to ﬁll

the information required for a better picture. Based

on the entities and relations, we identify patterns that

can be applied to recognize anomalies.

4.1 Internal Identity Management

Layer

The internal identity management layer encom-

passes all data related to identity management, includ-

ing digital identities and authentication.

Digital Identities. Users, data, applications, and

devices all have an identity that is managed and be-

longs to an organization. To access data, applications,

or devices, the user has to have the required permis-

sions that may be provided to them, for example, due

to roles or attributes. Following this, the management

system can be used as a source of security situational

awareness. The malicious and regular actor patterns

do not differ signiﬁcantly depending on the attack and

exact system. A honeypot may be applicable for fur-

ther information.

Authentication and Authorization. Before using,

for example, the service, the user has to be authen-

ticated. The most common method is a password.

However, other methods, including biometrics, may

be applied. Depending on the permissions, the ser-

vice decides on the authorization. Additional fea-

tures, such as those applied by risk-based authenti-

cation, may provide additional value for both authen-

tication and authorization. Again, the authentication

methods are crucial for security, whereas unusual pat-

terns may indicate a malicious actor.

Logged Authentication Actions. When a user au-

thenticates and uses a server, log ﬁles are written.

Log ﬁles related to digital identities and identity man-

agement systems (IdMS) can be found at the system,

IdMS, database, application, web server, and end-user

application (such as an SSI wallet on a smartphone)

level. The exact location depends on the actual ap-

plication. The log ﬁles may include identiﬁers, such

as session-related identiﬁers (IDs and tokens, among

Got Ya!: Sensors for Identity Management Speciﬁc Security Situational Awareness

143

others), IP addresses, transaction IDs, device ﬁnger-

prints and IDs, user IDs, and other identiﬁable data.

The exact identiﬁers are subject to log format, log

level, application, and policies, among others. Log

ﬁles are an essential source for security situational

awareness. However, identity-related attack patterns

have to be considered.

4.2 External Identity Layer

It is crucial to note that the scope of identity manage-

ment and digital identities extends beyond the internal

organization. The external identity layer plays a sig-

niﬁcant role in this more complex context.

Cross-Organizational Identity Management. As

summarized in Section 2, identity management is of-

ten not limited to a single organization. Different or-

ganizations may form a federation to use resources to-

gether. The identity management model (i.e., isolated,

centralized, federated, or self-sovereign) has implica-

tions on the attack pattern that every organization can

recognize, the impact, and the security incident re-

sponse (SIR) process. Hence, another source for se-

curity situational awareness is the other organizations

within a federation.

Usage of External Services. To make things more

complex, users may use external services that are

not part of a federation. For example, to submit a

manuscript, the researcher creates an account with

their name and work email address at a conference

management software system, such as EasyChair.

In social media, such as X (formerly Twitter) and

LinkedIn, they may provide insights into their work.

They may even reuse their work password, as shown

by (Florencio and Herley, 2007). All these data may

be used for malicious attempts. For example, pass-

word leaks allow malicious actors to stuff the cre-

dentials at other online services with the hope of tak-

ing over more accounts. If work-related data is in-

cluded, these attacks may target the work organiza-

tion. Hence, detecting password leakages is crucial,

and these services, as described by (Li et al., 2019),

should be included in the list of sources for security

situational awareness. If the leak is not detected and

added by typical leak services, it may be used by ma-

licious actors. The sharing of personal information is

even more complex to include. By sharing informa-

tion, potential malicious actors may gather data that

can be used for personalized attempts, such as social

engineering attacks. Email spam ﬁlters, human sen-

sors, and open-source intelligence honeypots like so-

cial media accounts may provide further input. Addi-

tionally, it might help to scan the Internet for identity-

related information (Walkow and Pöhn, 2023).

4.3 Threat Layer

(Pöhn and Hommel, 2022) differentiate IdMS, end-

user, and service account in their attack taxonomy

TaxIdMA. This differentiation is applied in the threat

layer. All elements have an identity. Hence, all identi-

ties may become relevant during an attack. The threat

layer describes the exposure of the network with its

systems and users through vulnerabilities that may be

within the software or users.

Users, thereby, mainly refer to end-users.

Nonetheless, IT personnel might be targeted later in

the attack lifecycle. Typically, service accounts that

have a vulnerability, such as a misconﬁguration, are

utilized during the attack lifecycle. The IdMS could

be the ﬁnal goal that can be reached by another vul-

nerability, such as a misconﬁguration. Another way is

to use another weakness, such as a common vulnera-

bility enumeration (CVE) for a speciﬁc software ver-

sion. Security events can be raised by security moni-

toring or humans.

4.4 Detection Layer

First, we derive the sensors before summarizing them.

Similarly to the threat layer, we use the distinction

between IdMS, end-user, and service account.

End-user. Passwords can be guessed, for example,

by spraying them on other services or brute-force at-

tacks, including credential stufﬁng. Phishing is one of

the primary initial access vector into an organization’s

network. However, variants of phishing involving so-

cial media, messenger, and other means are increas-

ingly being used.

Other threats may be human-in-the-middle

(MitM), usage of malware, and session hijacking, to

name a few examples. The malicious attackers may

use a different pattern that is deﬁned by the attack

and the means. Relevant features may include the

timing, session, device, IP address, username, and

password. As mentioned above, these may depend

on the actual system and attack. However, protocol

speciﬁcs have to be taken into account, as outlined in

Section 2 for the protocol of OAuth.

Service User. Regarding the attack lifecycle, ser-

vice accounts might come next. These may have

vulnerabilities related to software or conﬁguration

that allow the takeover by a malicious actor. In

the next step, the malicious actor may try to ﬁnd

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

144

further vulnerabilities and systems. Following this,

unusual behavior may hint at an attack. Thereby,

we try to recognize anomalies that can be detected

by host-based and network-based intrusion detection

systems (HIDS/NIDS). Further research may improve

the methods.

IdMS. One of the main goals might be the IdMS,

as seen with the SolarWinds’ Orion hack. An IdMS

can be targeted by taking over administration, deacti-

vated, or unused accounts, or using software-related

vulnerabilities. Depending on the IdMS, like AD,

the actions performed by the malicious actor may be

regular. This may increase the difﬁculty of detect-

ing anomalies. Besides unusual actions, honeypot ac-

counts and networks might be installed. However,

such an approach is still up to future work.

Proposed Sensors and Context Data. Table 1

summarizes the proposed sensors and context infor-

mation. We suggest classical security countermea-

sures or sensors, some adaptations, and additional

sensors. One example of adaptation is a honeypot

applied to identity management to recognize attacks.

Additionally, log ﬁle monitoring can help detect at-

tempts.

Regarding social engineering attacks and suspi-

cious computer behavior, human-as-a-security-sensor

(HaaSS) should be included (see, among others, Sec-

tion 4.2). In addition to the sensor information,

context information is required, according to (Husák

et al., 2021). Context information may include the

location, users (see also the parameters used by risk-

based authentication, which could be added to the log

data), version of the OS, software, services, and vul-

nerabilities (see Section 4.1). Hence, a collection of

this contextual data is needed. Preferably, it should

be maintained constantly. Husák et al. propose the

usage of NetFlow for passive monitoring and Nmap

for active monitoring.

In addition, the network plan, role concept (see

Section 4.1), and other documentation can help to no-

tice undocumented changes.

4.5 Comprehension

Comprehension describes the analysis, which re-

quires methods and characteristics for IdM-related at-

tacks. We outlined typical threats that have their pat-

tern. These may have simple reasons, such as a device

change since the smartphone was lost, or a malicious

actor. These patterns can be observed in, for example,

log ﬁles, which are the primary source of security sit-

uational awareness. Different identiﬁers might be in-

cluded in the log ﬁles depending on the actual system

and log level. The minimum characteristics required

to recognize these attacks are summarized in Table 2.

More characteristics may provide a better picture if

acceptable from a privacy perspective.

4.6 Projection

As the focus is on IdM, we again use the IdM-speciﬁc

information and the results from the comprehension

phase. An overview of user accounts, their access and

permissions on different systems, and a network plan

help identify the extent of malicious actions. Infor-

mation about previous and possible incidents provides

further input. This can be visualized in dashboards.

5 EXAMPLE OF OAuth

As outlined in Section 3, OAuth in its current ver-

sion 2.0 has some security drawbacks that are typ-

ically mitigated by applying the security best prac-

tices. For example, the authlib library has some

inherent security properties enabled by default. In

OAuth 2.1, changes are made to the security archi-

tecture of the framework, among other things (Pöhn

and Hommel, 2023). The grants classiﬁed as inse-

cure, the implicit grant and the resource owner pass-

word credentials grant, will be removed entirely from

the framework and will, therefore, no longer be usable

after the switch to version 2.1. We select the implicit

and authorization code grants to see the differences

between an insecure and a more secure grant. In ad-

dition, we use the threats described in (Lodderstedt

et al., 2013) and general threats in web applications.

We ﬁrst set up a test environment to evaluate our ex-

emplary implementation.

5.1 Test Environment

The test environment consists of a minimal OAuth

setup with an authorization server, a resource server,

and one client (i.e., all relevant entities) for each se-

lected grant. Due to its wide usage, Python is cho-

sen as a programming language in combination with

the Flask framework and authlib library. A MySQL

database is used to store persistent data.

Based on Section 4.4, the requests are logged

in log ﬁles using the format of TIMESTAMP -

Source-IP: PORT - Request-Line - Header.

With these data, we should recognize all attacks

in the test environment. Further features might be

added to differentiate malicious from regular actions

in the life environment. We select a rule-based

Got Ya!: Sensors for Identity Management Speciﬁc Security Situational Awareness

145

Table 1: Input for perception as ﬁrst phase of security situational awareness.

Internal Input Organizational Input External input

Log ﬁles Role concept Leak detection

AV systems Policies CERT warnings

Firewalls IdM lifecycles Vulnerability reports

IPS/IDS IdMSecMan Third-party reports

OSINT/IdM honeypot Network plan OSINT/IdM honeypot

NetFlow Security concept Update information

Network analyzer Other documentation Other external data

OSINT framework and HaaSS

Table 2: Overview of selected IdM-related attacks and their minimum characteristics.

Attack Characteristic

Password stufﬁng Password (hashed), IP address(es)

Wordlist Usernames, failures, IP address(es), maybe known input

Credential stufﬁng Usernames, IP address(es)

Brute-force attack Usernames, failures, IP address(es)

Session hijacking Different IP address and device/browser ﬁngerprint

Phishing Email, login with different IP address and device/browser ﬁngerprint

MitM Different IP address and reuse of session-related data

Malware Trafﬁc to external IP address(es), unusual behavior

approach as we have limited amount of data. In live

environments, isolation forest and hidden Markov

models might be better suited. The rules are created

based on known attacks, such as the reuse and replay

of tokens, cross-site scripting, and MitM attacks,

while applying OAuth protocol speciﬁcs.

In order to automate user actions, i.e., regular and

malicious actions, we use scripts. The malicious re-

quests can be started using this particular script. The

log ﬁles are used as input for the anomaly detec-

tion. When malicious requests are recognized by

this anomaly detection, they are then displayed in the

graphical user interface (GUI) for the IT personnel.

5.2 Practical Example

We apply the typical OAuth workﬂow, as described in

Section 2, in our example.

Creating a Client. As a prerequisite, a client has to

be created. A legitimate user is authenticated and gets

redirected to their user proﬁle. After clicking the ‘cre-

ate client’ button, a client is registered in the user’s

name. The client’s metadata is stored in the MySQL

database. Then, the client can initiate an OAuth grant.

By pressing the ‘Login with OAuth’ button, the URL

is redirected to the server. The request is also logged

in the log ﬁle. If the user has no current session, they

are redirected to the login site.

Creating a Session. Next, a session is created.

As soon as the user is authenticated to the server,

the server must agree to client-side access to their

data. When the user has authorized access to

their data through the client application (step 1), an

authorization_code is created by the server and

sent to the client (step 2). The client now creates the

client_code and sends it together with the received

authorization_code as a post request (step 3). The

server then creates a token, stores it in the MySQL

database, and sends it to the client as a header entry

(step 4). The client immediately redirects the user to

the user proﬁle page. The user name and email are

displayed on the user proﬁle. The client itself does

not have access to this data because it is stored in

the server’s database. To obtain this data, the client

must send the previously received access_token to

the server API in the form of a GET request as the

authorization header (step 5).

Detecting an Anomaly. The testing of the OAuth

test environment resulted in the creation of two

tokens: kvGWM72HDhLmatAoIiIxwgUbIhY92elmFs9

DkKKlht for the authorization code grant and

XfKybKsgXU61HuBy1Kpy8Dy85GPj3TwKbpQSlRJnAd

for the implicit grant. Every client’s access to pro-

tected resources results in the creation of a new

token. The server saves all incoming requests. The

anomaly detection application reads the created

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

146

log ﬁle header_logs.log in a loop. The anomaly

detection application recognizes and displays tokens

used multiple times as anomalies. If the malicious

actor (in the test environment, it is our script) has

gained the token, for example, via a human-in-the-

middle attack, they may reuse it to request access

to resources. If the malicious actor uses the token

of the authorization code grant to request protected

resources, this request results in an anomaly and is

displayed in the security personnel GUI, as shown in

Figure 2. As a second aspect, the user-agent curl

would also result in an anomaly.

Figure 2: Security personnel GUI showing a malicious

OAuth request.

The number of features that can be used for the

rules depends on the information logged. The ac-

curacy also depends on the details and number of

rules used. Furthermore, other sensors add valuable

data, such as leaked passwords on other websites, and

OAuth-speciﬁc rules should not be the only source.

6 CONCLUSION AND OUTLOOK

As identity and access management are crucial as-

sets that malicious actors target, the security measures

have to adjust and consider the speciﬁcations of iden-

tity management and its protocols. We proposed a

generic security situational awareness approach spe-

ciﬁc to IdM to improve awareness in this ﬁeld. Based

on related work, we noticed that risk-based authen-

tication uses several features that can be applied as

sensors. Next, we identiﬁed several sensors, other

sources, and attack patterns. Then, we practically

showed the test environment and proof-of-concept

implementation for OAuth.

The proposed concept is the ﬁrst one speciﬁc to

identity management. It comprises various sources

and may provide the security personnel with fur-

ther insights into the security of their infrastructure.

However, as it mainly concentrates on sensors, other

sources, and attack patterns, it is only the ﬁrst step

towards security situational awareness. As identity

management is directly linked to the handling of per-

sonally identiﬁable information, we were not allowed

to use a practical example with (pseudonymized) real

world logs. Instead, a test environment for OAuth was

chosen that will be extended in future work. Follow-

ing this, the efﬁciency of the approach was not evalu-

ated, since the detection was done in real time within

the test environment. To the best of our knowledge,

this is the ﬁrst IdM-speciﬁc approach. By switching

the focus to identities, insights might be gathered, as

shown with the example of OAuth.

However, it is the ﬁrst step, and the implementa-

tion has to be extended in future work. In addition, we

want to integrate external sensors and evaluate the ap-

proach with actual data. Since identity management

is often cross-organizational, we ﬁnally want to inves-

tigate in cross-organizational situational awareness.

REFERENCES

Benolli, M., Mirheidari, S. A., Arshad, E., and Crispo, B.

(2021). The Full Gamut of an Attack: An Empirical

Analysis of OAuth CSRF in the Wild. In Bilge, L.,

Cavallaro, L., Pellegrino, G., and Neves, N., editors,

Detection of Intrusions and Malware, and Vulnerabil-

ity Assessment, pages 21–41, Cham. Springer Interna-

tional Publishing.

Endsley, M. R. (1988). Design and Evaluation for Situation

Awareness Enhancement. Proceedings of the Human

Factors Society Annual Meeting, 32(2):97–101.

Evesti, A., Kanstrén, T., and Frantti, T. (2017). Cyberse-

curity situational awareness taxonomy. In Interna-

tional Conference On Cyber Situational Awareness,

Data Analytics And Assessment (Cyber SA), pages 1–

Fett, D., Küsters, R., and Schmitz, G. (2016). A Compre-

hensive Formal Security Analysis of OAuth 2.0. In

Proceedings of the 2016 ACM SIGSAC Conference on

Computer and Communications Security (CCS), page

1204–1215.

Florencio, D. and Herley, C. (2007). A large-scale study of

web password habits. In Proceedings of the 16th In-

ternational Conference on World Wide Web (WWW),

page 657–666.

Franke, U. and Brynielsson, J. (2014). Cyber situational

awareness – a systematic review of the literature.

Computers & Security, 46:18–31.

Gutzwiller, R., Dykstra, J., and Payne, B. (2020). Gaps and

Got Ya!: Sensors for Identity Management Speciﬁc Security Situational Awareness

147

Opportunities in Situational Awareness for Cyberse-

curity. Digital Threats, 1(3).

Hardt, D. (2012). The OAuth 2.0 Authorization Framework.

RFC 6749.

Hardt, D., Parecki, A., and Lodderstedt, T. (2024). The

OAuth 2.1 Authorization Framework. Internet-Draft

draft-ietf-oauth-v2-1-10, Internet Engineering Task

Force. Work in Progress.

Headquarters, Department of the Army (2021). Advanced

Situational Awareness. Technical report.

Husák, M., Jirsík, T., and Yang, S. J. (2020). SoK: con-

temporary issues and challenges to enable cyber situa-

tional awareness for network security. In Proceedings

of the 15th International Conference on Availability,

Reliability and Security (ARES).

Husák, M., Khoury, J., Klisura, D., and Bou-Harb, E.

(2023). On the Provision of Network-Wide Cyber

Situational Awareness via Graph-Based Analytics. In

Collet, P., Gardashova, L., El Zant, S., and Abdulka-

rimova, U., editors, Complex Computational Ecosys-

tems, pages 167–179, Cham. Springer Nature Switzer-

land.

Husák, M., Laštovi

cka, M., and Tovar

nák, D. (2021). Sys-

tem for Continuous Collection of Contextual Informa-

tion for Network Security Management and Incident

Handling. In Proceedings of the 16th International

Conference on Availability, Reliability and Security

(ARES).

Innocenti, T., Golinelli, M., Onarlioglu, K., Mirheidari, A.,

Crispo, B., and Kirda, E. (2023). OAuth 2.0 Redi-

rect URI Validation Falls Short, Literally. In Proceed-

ings of the 39th Annual Computer Security Applica-

tions Conference (ACSAC), page 256–267.

Jannett, L., Mladenov, V., Mainka, C., and Schwenk, J.

(2022). Distinct: Identity theft using in-browser com-

munications in dual-window single sign-on. In Pro-

ceedings of the 2022 ACM SIGSAC Conference on

Computer and Communications Security (CCS), page

1553–1567.

Legg, P. and Blackman, T. (2019). Tools and Techniques

for Improving Cyber Situational Awareness of Tar-

geted Phishing Attacks. In International Conference

on Cyber Situational Awareness, Data Analytics And

Assessment (Cyber SA), pages 1–4.

Li, L., Pal, B., Ali, J., Sullivan, N., Chatterjee, R., and Ris-

tenpart, T. (2019). Protocols for Checking Compro-

mised Credentials. In Proceedings of the 2019 ACM

SIGSAC Conference on Computer and Communica-

tions Security (CCS), page 1387–1403.

Lodderstedt, T., McGloin, M., and Hunt, P. (2013). OAuth

2.0 Threat Model and Security Considerations. RFC

6819.

Nour, B., Pourzandi, M., and Debbabi, M. (2023). A Sur-

vey on Threat Hunting in Enterprise Networks. IEEE

Communications Surveys & Tutorials, 25(4):2299–

2324.

OpenID Foundation (2024). OpenID for Veriﬁable Creden-

tials - Overview. https://openid.net/sg/openid4vc/.

Peisert, S., Schneier, B., Okhravi, H., Massacci, F., Benzel,

T., Landwehr, C., Mannan, M., Mirkovic, J., Prakash,

A., and Michael, J. B. (2021). Perspectives on the So-

larWinds Incident. IEEE Security & Privacy, 19(2):7–

13.

Pöhn, D. and Hommel, W. (2022). TaxIdMA: Towards

a Taxonomy for Attacks related to Identities. In

Proceedings of the 17th International Conference on

Availability, Reliability and Security (ARES).

Pöhn, D. and Hommel, W. (2023). New Directions and

Challenges within Identity and Access Management.

IEEE Communications Standards Magazine, 7(2):84–

90.

Rodriguez, A. and Okamura, K. (2019). Generating

Real Time Cyber Situational Awareness Information

Through Social Media Data Mining. In 43rd An-

nual Computer Software and Applications Conference

(COMPSAC), volume 2, pages 502–507.

Sterle, L. and Bhunia, S. (2021). On SolarWinds

Orion Platform Security Breach. In SmartWorld,

Ubiquitous Intelligence & Computing, Advanced &

Trusted Computing, Scalable Computing & Commu-

nications, Internet of People and Smart City Inno-

vation (SmartWorld/SCALCOM/UIC/ATC/IOP/SCI),

pages 636–641.

Tianﬁeld, H. (2016). Cyber Security Situational Awareness.

In International Conference on Internet of Things

(iThings) and IEEE Green Computing and Commu-

nications (GreenCom) and IEEE Cyber, Physical and

Social Computing (CPSCom) and IEEE Smart Data

(SmartData), pages 782–787.

Walkow, M. and Pöhn, D. (2023). Systematically Searching

for Identity-Related Information in the Internet with

OSINT Tools. In Proceedings of the 9th International

Conference on Information Systems Security and Pri-

vacy (ICISSP), pages 402–409.

Wang, H., Zhang, Y., Li, J., and Gu, D. (2016). The

Achilles heel of OAuth: a multi-platform study of

OAuth-based authentication. In Proceedings of the

32nd Annual Conference on Computer Security Ap-

plications (ACSAC), page 167–176.

Yin, X., Yurcik, W., Treaster, M., Li, Y., and Lakkaraju,

K. (2004). VisFlowConnect: netﬂow visualizations of

link relationships for security situational awareness.

In Proceedings of the 2004 ACM Workshop on Vi-

sualization and Data Mining for Computer Security

(VizSEC/DMSEC), page 26–34.

Zhang, J., Feng, H., Liu, B., and Zhao, D. (2023). Survey of

Technology in Network Security Situation Awareness.

Sensors, 23(5).

Zurowski, S., Lord, G., and Baggili, I. (2022). A Quanti-

tative Analysis of Offensive Cyber Operation (OCO)

Automation Tools. In Proceedings of the 17th Interna-

tional Conference on Availability, Reliability and Se-

curity (ARES).

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

148