Y. Zhauniarovich
info
Please Note
<p>This page displays the records of the person named above and is not linked to a unique person identifier. This record may need to be merged to a profile.</p>
22 records found
1
VSMEx
A Collection Tool and a Dataset of Malicious VS Code Extensions: Data/Toolset Paper
Conference paper
(2026)
-
Kotaiba Alachkar, Dirk Gaastra, Olga Gadyatskaya, Eduardo Barbaro, Michel Van Eeten, Yury Zhauniarovich
Visual Studio Code (VS Code) is one of the most widely used code editors, and its extension ecosystem has increasingly become a target for software supply chain attacks. Developing and validating effective detection techniques in this area requires ground-Truth data with both benign and malicious samples. While benign samples are easy to obtain, no publicly available or continuously updated dataset exists for malicious VS Code extensions. To address this gap, we built VSMEx, a continuously updated dataset of malicious VS Code extensions derived from Microsoft's official malicious and removed lists. Over a deployment period of more than three months, VSMEx successfully captured 214 extensions, demonstrating the viability of our approach. In this work, we present an initial analysis of the resulting dataset and share the associated metadata and the list of flagged or removed extensions collected during this period. In addition, we provide controlled access to the dataset itself, facilitating further research and contributing to the security of the VS Code ecosystem. Note that VSMEx continues to operate, making the resulting dataset well suited for training and validation in continuous machine learning settings.
...
Visual Studio Code (VS Code) is one of the most widely used code editors, and its extension ecosystem has increasingly become a target for software supply chain attacks. Developing and validating effective detection techniques in this area requires ground-Truth data with both benign and malicious samples. While benign samples are easy to obtain, no publicly available or continuously updated dataset exists for malicious VS Code extensions. To address this gap, we built VSMEx, a continuously updated dataset of malicious VS Code extensions derived from Microsoft's official malicious and removed lists. Over a deployment period of more than three months, VSMEx successfully captured 214 extensions, demonstrating the viability of our approach. In this work, we present an initial analysis of the resulting dataset and share the associated metadata and the list of flagged or removed extensions collected during this period. In addition, we provide controlled access to the dataset itself, facilitating further research and contributing to the security of the VS Code ecosystem. Note that VSMEx continues to operate, making the resulting dataset well suited for training and validation in continuous machine learning settings.
Software vulnerabilities - particularly in open-source software (OSS) components, which are now embedded in nearly every application - pose major security and privacy risks. Existing tools and research focus largely on vulnerabilities listed in the Common Vulnerabilities and Exposures (CVE) system, leaving those without CVE identifiers often overlooked. In this study, we aim to estimate the number of such CVE-less vulnerabilities in OSS projects by systematically analyzing project issue trackers to identify security-related reports that could qualify as CVEs. We use an AI-human collaborative approach, combining AI-based issue pre-filtering with expert validation to efficiently and accurately estimate the prevalence of these overlooked vulnerabilities.
We closely examined four large C++ projects and found that approximately 1.55% of all reported issues were classified by our model as security-related. Expert validation performed by the CVE Numbering Authority (CNA) Administrator on the gRPC project revealed that about 22% of these predicted security-related issues correspond to real, previously untracked vulnerabilities. This number is nearly five times greater than the total number of CVEs listed for this project in the National Vulnerability Database (NVD). These results reveal a gap in today's vulnerability disclosure ecosystem: many vulnerabilities are publicly disclosed in issue trackers yet never formally communicated through the CVE program, leaving them largely unexplored and potentially unaddressed. ...
We closely examined four large C++ projects and found that approximately 1.55% of all reported issues were classified by our model as security-related. Expert validation performed by the CVE Numbering Authority (CNA) Administrator on the gRPC project revealed that about 22% of these predicted security-related issues correspond to real, previously untracked vulnerabilities. This number is nearly five times greater than the total number of CVEs listed for this project in the National Vulnerability Database (NVD). These results reveal a gap in today's vulnerability disclosure ecosystem: many vulnerabilities are publicly disclosed in issue trackers yet never formally communicated through the CVE program, leaving them largely unexplored and potentially unaddressed. ...
Software vulnerabilities - particularly in open-source software (OSS) components, which are now embedded in nearly every application - pose major security and privacy risks. Existing tools and research focus largely on vulnerabilities listed in the Common Vulnerabilities and Exposures (CVE) system, leaving those without CVE identifiers often overlooked. In this study, we aim to estimate the number of such CVE-less vulnerabilities in OSS projects by systematically analyzing project issue trackers to identify security-related reports that could qualify as CVEs. We use an AI-human collaborative approach, combining AI-based issue pre-filtering with expert validation to efficiently and accurately estimate the prevalence of these overlooked vulnerabilities.
We closely examined four large C++ projects and found that approximately 1.55% of all reported issues were classified by our model as security-related. Expert validation performed by the CVE Numbering Authority (CNA) Administrator on the gRPC project revealed that about 22% of these predicted security-related issues correspond to real, previously untracked vulnerabilities. This number is nearly five times greater than the total number of CVEs listed for this project in the National Vulnerability Database (NVD). These results reveal a gap in today's vulnerability disclosure ecosystem: many vulnerabilities are publicly disclosed in issue trackers yet never formally communicated through the CVE program, leaving them largely unexplored and potentially unaddressed.
We closely examined four large C++ projects and found that approximately 1.55% of all reported issues were classified by our model as security-related. Expert validation performed by the CVE Numbering Authority (CNA) Administrator on the gRPC project revealed that about 22% of these predicted security-related issues correspond to real, previously untracked vulnerabilities. This number is nearly five times greater than the total number of CVEs listed for this project in the National Vulnerability Database (NVD). These results reveal a gap in today's vulnerability disclosure ecosystem: many vulnerabilities are publicly disclosed in issue trackers yet never formally communicated through the CVE program, leaving them largely unexplored and potentially unaddressed.
PeeringDB
Still Accurate a Decade Later?
PeeringDB consists of self-reported data and is widely used to facilitate network interconnection, automation, and research, often serving as a ground truth source. However, the accuracy of its data remains a significant concern. In this study, we evaluate the reliability of PeeringDB using a dataset from January 2025. Our analysis finds certain inconsistencies in key data elements. We identified ASNs that remain present in the database despite no longer being assigned. Analysis of self-reported network types reveals that 28.58% of networks either do not report a type or choose not to disclose it, challenging its use to support interconnection decisions. Further comparison of the available network types against their equivalent classifications from ASdb and IPinfo shows considerable disagreement. Manual validation of networks in the "Government"category reveals that only 77.10% of ASNs provided accurate network type. Finally, the consistency check of self-reported prefix counts with routing data from RIPE RIS and CAIDA ASRank indicated significant inconsistencies. Our findings underscore the need for enhanced validation mechanisms to improve the reliability of data provided by PeeringDB for improving its research and operational uses.
...
PeeringDB consists of self-reported data and is widely used to facilitate network interconnection, automation, and research, often serving as a ground truth source. However, the accuracy of its data remains a significant concern. In this study, we evaluate the reliability of PeeringDB using a dataset from January 2025. Our analysis finds certain inconsistencies in key data elements. We identified ASNs that remain present in the database despite no longer being assigned. Analysis of self-reported network types reveals that 28.58% of networks either do not report a type or choose not to disclose it, challenging its use to support interconnection decisions. Further comparison of the available network types against their equivalent classifications from ASdb and IPinfo shows considerable disagreement. Manual validation of networks in the "Government"category reveals that only 77.10% of ASNs provided accurate network type. Finally, the consistency check of self-reported prefix counts with routing data from RIPE RIS and CAIDA ASRank indicated significant inconsistencies. Our findings underscore the need for enhanced validation mechanisms to improve the reliability of data provided by PeeringDB for improving its research and operational uses.
Journal article
(2026)
-
Abdulkhamid Mukhamedov, Vanessa Simões de Azevedo, Michel van Eeten, Jolien Ubacht, Yury Zhauniarovich
The growing economic value of blockchain-driven financial applications brings increasing risks. In recent years, EU regulators felt the urgent need to address the financial and security risks that digital currencies might pose if left unsupervised. In 2020, the European Commission proposed a draft regulation called Markets in Crypto-Assets (MiCA). It sets out the rules for the crypto-asset issuers and service providers located in the EU or serving EU clients. To date, there is no evaluation of the risks covered by the proposed regulations besides the Commission’s own evaluation.
We conducted a study to identify the risk perceptions of different stakeholder groups in the market by interviewing 20 representatives of Crypto-Asset Service Providers, Crypto-Asset Issuers, Institutional Investors, and Legal Experts. We then compared the risks deemed relevant by the stakeholder groups with the risks covered in the MiCA framework. That allowed us to identify which risks and stakeholder groups’ concerns are insufficiently covered by the current version of the MiCA framework. As a result, we show that Crypto-Asset Issuers’ risks are the least addressed in the current MiCA version. Specifically, residual risks remain with regard to smart contracts, oracles, and transactions. These risks should be considered for upcoming amendments to the regulation. ...
We conducted a study to identify the risk perceptions of different stakeholder groups in the market by interviewing 20 representatives of Crypto-Asset Service Providers, Crypto-Asset Issuers, Institutional Investors, and Legal Experts. We then compared the risks deemed relevant by the stakeholder groups with the risks covered in the MiCA framework. That allowed us to identify which risks and stakeholder groups’ concerns are insufficiently covered by the current version of the MiCA framework. As a result, we show that Crypto-Asset Issuers’ risks are the least addressed in the current MiCA version. Specifically, residual risks remain with regard to smart contracts, oracles, and transactions. These risks should be considered for upcoming amendments to the regulation. ...
The growing economic value of blockchain-driven financial applications brings increasing risks. In recent years, EU regulators felt the urgent need to address the financial and security risks that digital currencies might pose if left unsupervised. In 2020, the European Commission proposed a draft regulation called Markets in Crypto-Assets (MiCA). It sets out the rules for the crypto-asset issuers and service providers located in the EU or serving EU clients. To date, there is no evaluation of the risks covered by the proposed regulations besides the Commission’s own evaluation.
We conducted a study to identify the risk perceptions of different stakeholder groups in the market by interviewing 20 representatives of Crypto-Asset Service Providers, Crypto-Asset Issuers, Institutional Investors, and Legal Experts. We then compared the risks deemed relevant by the stakeholder groups with the risks covered in the MiCA framework. That allowed us to identify which risks and stakeholder groups’ concerns are insufficiently covered by the current version of the MiCA framework. As a result, we show that Crypto-Asset Issuers’ risks are the least addressed in the current MiCA version. Specifically, residual risks remain with regard to smart contracts, oracles, and transactions. These risks should be considered for upcoming amendments to the regulation.
We conducted a study to identify the risk perceptions of different stakeholder groups in the market by interviewing 20 representatives of Crypto-Asset Service Providers, Crypto-Asset Issuers, Institutional Investors, and Legal Experts. We then compared the risks deemed relevant by the stakeholder groups with the risks covered in the MiCA framework. That allowed us to identify which risks and stakeholder groups’ concerns are insufficiently covered by the current version of the MiCA framework. As a result, we show that Crypto-Asset Issuers’ risks are the least addressed in the current MiCA version. Specifically, residual risks remain with regard to smart contracts, oracles, and transactions. These risks should be considered for upcoming amendments to the regulation.
Conference paper
(2026)
-
Kotaiba Alachkar, Eduardo Barbaro, Cristiano Giuffrida, Michel Van Eeten, Yury Zhauniarovich
Threat actors have extensively used cloud services as covert channels for Command & Control (C2) and data exfiltration. In response, best practices for enterprise security recommend blocking unsanctioned cloud services and monitoring egress traffic to detect data exfiltration. In this paper, we demonstrate that these defenses fail in the context of first-party services offered by major Cloud Service Providers (CSPs), such as Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP). To provide their services, CSPs require enterprise clients to create broad network openings to some of their services, which means that blocking access to other tenants' resources for those services is not possible. Additionally, their tight integration into enterprise IT means large volumes of traffic move from the enterprise to the cloud services, making it difficult to distinguish malicious from legitimate activity.To demonstrate the extent of this threat, we implement practical covert C2 channels through six first-party services across Azure, AWS, and GCP. Our simulated attacks demonstrate successful data exfiltration despite mature enterprise-level security controls. These attacks are both stealthy (i.e., evading OS-level and network-level detection) and effective (i.e., achieving practical exfiltration rates of over 400 Mbps). To complement our technical evaluation, we conducted a focus group study with security professionals. Participants acknowledged that awareness of this threat has recently increased, although it remains largely limited to the security experts inside enterprises. They also agreed that detecting such attacks is extraordinarily difficult. Our findings highlight a systemic blind spot in enterprise security and call for coordinated mitigation efforts between CSPs and developers of third-party enterprise services.
...
Threat actors have extensively used cloud services as covert channels for Command & Control (C2) and data exfiltration. In response, best practices for enterprise security recommend blocking unsanctioned cloud services and monitoring egress traffic to detect data exfiltration. In this paper, we demonstrate that these defenses fail in the context of first-party services offered by major Cloud Service Providers (CSPs), such as Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP). To provide their services, CSPs require enterprise clients to create broad network openings to some of their services, which means that blocking access to other tenants' resources for those services is not possible. Additionally, their tight integration into enterprise IT means large volumes of traffic move from the enterprise to the cloud services, making it difficult to distinguish malicious from legitimate activity.To demonstrate the extent of this threat, we implement practical covert C2 channels through six first-party services across Azure, AWS, and GCP. Our simulated attacks demonstrate successful data exfiltration despite mature enterprise-level security controls. These attacks are both stealthy (i.e., evading OS-level and network-level detection) and effective (i.e., achieving practical exfiltration rates of over 400 Mbps). To complement our technical evaluation, we conducted a focus group study with security professionals. Participants acknowledged that awareness of this threat has recently increased, although it remains largely limited to the security experts inside enterprises. They also agreed that detecting such attacks is extraordinarily difficult. Our findings highlight a systemic blind spot in enterprise security and call for coordinated mitigation efforts between CSPs and developers of third-party enterprise services.
APT to Disagree
A Comparative Analysis of Attribution in Commercial TI
Conference paper
(2026)
-
Aksel Ethembabaoglu, Rolf Van Wegberg, Yury Zhauniarovich, Michel Van Eeten
Attributed cyber threat intelligence (TI) plays an important role in the effective mitigation of cyber attacks. Yet, despite the central role of attribution in policy, practice, and vendor reporting, little is known about the coverage and reliability of attribution by threat intelligence vendors. No study has systematically investigated attribution across a large set of leading TI vendors. We close this gap and provide a longitudinal comparative analysis across 13.5 million IOCs collected over the last 14 years from seven vendors. To compare IOC attribution across vendors, we normalize heterogeneous feeds and reconcile actor names using an evaluated and augmented version of MISP Threat Actor Galaxy (MISP TAG). Next, we address two questions: (i) what is the scope of actor-tracking by vendors, and (ii) how consistent is attribution among vendors? We find that the majority of actors tracked by one vendor are not tracked by the other. Furthermore, IOCs observed by multiple TI vendors are rare (1 %), illustrating that commercial TI feeds, like open-source feeds, primarily provide singleton IOCs. We also find limited overlap in IOCs for jointly tracked actors by two vendors. We measure attribution agreement among vendors with Krippendorff's α. We find mostly moderate agreement among vendors for actor attribution. By contrast, country attribution has high agreement. Our results have implications for actor-centric defenses, compliance, and geopolitical uses of attribution.
...
Attributed cyber threat intelligence (TI) plays an important role in the effective mitigation of cyber attacks. Yet, despite the central role of attribution in policy, practice, and vendor reporting, little is known about the coverage and reliability of attribution by threat intelligence vendors. No study has systematically investigated attribution across a large set of leading TI vendors. We close this gap and provide a longitudinal comparative analysis across 13.5 million IOCs collected over the last 14 years from seven vendors. To compare IOC attribution across vendors, we normalize heterogeneous feeds and reconcile actor names using an evaluated and augmented version of MISP Threat Actor Galaxy (MISP TAG). Next, we address two questions: (i) what is the scope of actor-tracking by vendors, and (ii) how consistent is attribution among vendors? We find that the majority of actors tracked by one vendor are not tracked by the other. Furthermore, IOCs observed by multiple TI vendors are rare (1 %), illustrating that commercial TI feeds, like open-source feeds, primarily provide singleton IOCs. We also find limited overlap in IOCs for jointly tracked actors by two vendors. We measure attribution agreement among vendors with Krippendorff's α. We find mostly moderate agreement among vendors for actor attribution. By contrast, country attribution has high agreement. Our results have implications for actor-centric defenses, compliance, and geopolitical uses of attribution.
“Tell Them They Are a Responsible Entity, Not a Customer”
Understanding Practitioner Challenges in Sector CSIRTs
Conference paper
(2026)
-
Aksel Ethembabaoglu, Natalia I. Kadenko, Yana Angelova, Yury Zhauniarovich, Rolf van Wegberg, Simon Parkin, Michel van Eeten
In this paper, we study the experiences of practitioners in sectoral Computer Security Incident Response Teams (CSIRTs)—specialized teams that mediate between national cybersecurity authorities and the sector constituency. Through interviews with 18 professionals connected to the Informatiebeveiligingsdienst (IBD-CSIRT) for Dutch local governments, we uncover tensions in how key services are valued. For vulnerability notifications, while the CSIRT staff consider them a core service, many constituents hardly mention them, and systemic gaps in information forwarding mean that crucial alerts often never arrive. We extend these insights with 5 interviews across other sector CSIRTs and a validation workshop with 7 participants, all security officers from sector CSIRTs, revealing shared challenges in balancing technical expertise with sector knowledge, building trust-based relationships, and navigating institutional bottlenecks. Our findings contribute the first systematic account of how sector CSIRT professionals understand and perform their role, highlighting the tensions in providing sector-wide support to professionals with differing security needs.
...
In this paper, we study the experiences of practitioners in sectoral Computer Security Incident Response Teams (CSIRTs)—specialized teams that mediate between national cybersecurity authorities and the sector constituency. Through interviews with 18 professionals connected to the Informatiebeveiligingsdienst (IBD-CSIRT) for Dutch local governments, we uncover tensions in how key services are valued. For vulnerability notifications, while the CSIRT staff consider them a core service, many constituents hardly mention them, and systemic gaps in information forwarding mean that crucial alerts often never arrive. We extend these insights with 5 interviews across other sector CSIRTs and a validation workshop with 7 participants, all security officers from sector CSIRTs, revealing shared challenges in balancing technical expertise with sector knowledge, building trust-based relationships, and navigating institutional bottlenecks. Our findings contribute the first systematic account of how sector CSIRT professionals understand and perform their role, highlighting the tensions in providing sector-wide support to professionals with differing security needs.
Conference paper
(2025)
-
Kotaiba Alachkar, Dirk Gaastra, Eduardo Barbaro, Michel van Eeten, Yury Zhauniarovich
Endpoint Detection and Response (EDR) systems provide continuous monitoring, threat detection, and response capabilities. This has driven their widespread adoption in enterprises, making them a key part of an enterprise's security architecture. However, EDR systems are a double-edged sword, and in this study, we demonstrate how this class of systems can be employed for offensive use. Unlike prior studies that focused on evasion and tampering, we introduce the new concept of EDR repurposing, which we call EvilEDR. Our analysis shows that EvilEDR can be used to execute arbitrary commands via the response console, transfer tools, exfiltrate data, and passively collect system information to facilitate further exploitation and lateral movement. EvilEDR operates covertly, masquerading as a legitimate process and communicating seamlessly with trusted domains. Additionally, we show that EvilEDR can impair defenses by registering its own EPP as the default. It can also isolate the host from the network, severing telemetry and response channels essential for enterprise defense mechanisms. Fortunately, EvilEDR can be effectively detected and mitigated, and in this paper, we propose concrete and actionable defense strategies to achieve this.
...
Endpoint Detection and Response (EDR) systems provide continuous monitoring, threat detection, and response capabilities. This has driven their widespread adoption in enterprises, making them a key part of an enterprise's security architecture. However, EDR systems are a double-edged sword, and in this study, we demonstrate how this class of systems can be employed for offensive use. Unlike prior studies that focused on evasion and tampering, we introduce the new concept of EDR repurposing, which we call EvilEDR. Our analysis shows that EvilEDR can be used to execute arbitrary commands via the response console, transfer tools, exfiltrate data, and passively collect system information to facilitate further exploitation and lateral movement. EvilEDR operates covertly, masquerading as a legitimate process and communicating seamlessly with trusted domains. Additionally, we show that EvilEDR can impair defenses by registering its own EPP as the default. It can also isolate the host from the network, severing telemetry and response channels essential for enterprise defense mechanisms. Fortunately, EvilEDR can be effectively detected and mitigated, and in this paper, we propose concrete and actionable defense strategies to achieve this.
Trust but Verify
An Assessment of Vulnerability Tagging Services
Conference paper
(2025)
-
Szu-Chun Huang, Harm Griffioen, Max van der Horst, Georgios Smaragdakis, Michel van Eeten, Yury Zhauniarovich
Internet-wide scanning services are widely used for attack surface discovery across organizations and the Internet. Enterprises, government agencies, and researchers rely on these tools to assess risks to Internet-facing infrastructure. However, their reliability and trustworthiness remain largely unexamined. This paper addresses this gap by comparing results from three commercial scanners – Shodan, ONYPHE, and LeakIX – with findings from our independent experiments using verified Nuclei templates, designed to identify specific vulnerabilities through crafted benign requests. We found that the payload based detections of Shodan are mostly confirmed. Yet, Nuclei finds many more vulnerable endpoints, so defenders might face massive underreporting. For Shodan’s banner-based detections, the opposite issue arises: a significant overreporting of false positives. This indicates that banner-based detections are unreliable. Moreover, three commercial services and Nuclei scans exhibit significant discrepancies. Our work has implications for industry users, policymakers, and the many academic researchers who rely on the results provided by these attack surface management services. By highlighting their shortcomings in vulnerability monitoring, this work serves as a call for action to advance and standardize such services to enhance their trustworthiness.
...
Internet-wide scanning services are widely used for attack surface discovery across organizations and the Internet. Enterprises, government agencies, and researchers rely on these tools to assess risks to Internet-facing infrastructure. However, their reliability and trustworthiness remain largely unexamined. This paper addresses this gap by comparing results from three commercial scanners – Shodan, ONYPHE, and LeakIX – with findings from our independent experiments using verified Nuclei templates, designed to identify specific vulnerabilities through crafted benign requests. We found that the payload based detections of Shodan are mostly confirmed. Yet, Nuclei finds many more vulnerable endpoints, so defenders might face massive underreporting. For Shodan’s banner-based detections, the opposite issue arises: a significant overreporting of false positives. This indicates that banner-based detections are unreliable. Moreover, three commercial services and Nuclei scans exhibit significant discrepancies. Our work has implications for industry users, policymakers, and the many academic researchers who rely on the results provided by these attack surface management services. By highlighting their shortcomings in vulnerability monitoring, this work serves as a call for action to advance and standardize such services to enhance their trustworthiness.
With the growing reliance on cloud services for storage and deployment, securing cloud environments has become critically important. Cloud storage solutions like AWS S3, Google Cloud Storage, and Azure Blob Storage are widely used to store vast amounts of data, including sensitive configuration files used in software development. These files often contain secrets such as API keys and credentials. Misconfigured cloud buckets can inadvertently expose these secrets, leading to unauthorized access to services and security breaches. In this work, we explore the issue of secret leaks in files exposed through misconfigured cloud storage. Our analysis covers a variety of file formats frequently used in development and focuses on different secrets that have diverse types of impact as well as the possibility for a non-intrusive validation. By systematically scanning a large collection of publicly acces-sible cloud buckets, we identified 215 instances where sensitive credentials were exposed. These secrets provide unauthorized access to services like databases, cloud infrastructure, and third-party APIs, posing significant security risks. Upon discovering these leaks, we responsibly reported them to the respective organizations and cloud service providers and measured the outcomes of the disclosure process. Our respon-sible disclosure efforts led to the remediation of 95 issues. Twenty organizations directly communicated their actions back to us, promptly addressing the issues, while the remaining fixes were implemented without direct feedback to the disclosers. Our study highlights the global prevalence of secret leaks in cloud storage and emphasizes the varied responses from organizations in mitigating these critical security risks.
...
With the growing reliance on cloud services for storage and deployment, securing cloud environments has become critically important. Cloud storage solutions like AWS S3, Google Cloud Storage, and Azure Blob Storage are widely used to store vast amounts of data, including sensitive configuration files used in software development. These files often contain secrets such as API keys and credentials. Misconfigured cloud buckets can inadvertently expose these secrets, leading to unauthorized access to services and security breaches. In this work, we explore the issue of secret leaks in files exposed through misconfigured cloud storage. Our analysis covers a variety of file formats frequently used in development and focuses on different secrets that have diverse types of impact as well as the possibility for a non-intrusive validation. By systematically scanning a large collection of publicly acces-sible cloud buckets, we identified 215 instances where sensitive credentials were exposed. These secrets provide unauthorized access to services like databases, cloud infrastructure, and third-party APIs, posing significant security risks. Upon discovering these leaks, we responsibly reported them to the respective organizations and cloud service providers and measured the outcomes of the disclosure process. Our respon-sible disclosure efforts led to the remediation of 95 issues. Twenty organizations directly communicated their actions back to us, promptly addressing the issues, while the remaining fixes were implemented without direct feedback to the disclosers. Our study highlights the global prevalence of secret leaks in cloud storage and emphasizes the varied responses from organizations in mitigating these critical security risks.
IAM Role Diet
A Scalable Approach to Detecting RBAC Data Inefficiencies
More than three decades after its introduction, Role-Based Access Control (RBAC) continues to be one of the most widely used access control models in organizations. This popularity stems from its simplicity, the reduced risk of errors, and its clear alignment with business processes. However, the primarily manual nature of data management in RBAC systems, coupled with a lack of oversight, can lead to various inefficiencies over time. These may include roles that are not assigned to any users or roles that have identical sets of permissions. Such issues can slow down systems that rely on these data and, more critically, complicate auditing processes, increasing the risk of security gaps and compliance violations.In this paper, we present a taxonomy of inefficiencies that can arise in RBAC data over time and propose a framework for detecting these inefficiencies. We specifically focus on the most resource-intensive inefficiencies, namely roles that share the same or similar users or permissions. To address these issues, we propose three detection methods, including a custom algorithm we developed. We evaluate these methods using synthetic datasets, demonstrating that our algorithm significantly outperforms baseline approaches. Its efficiency allows us to identify these inefficiencies even on a standard laptop used by large organizations. Furthermore, we applied our framework to real RBAC data from a large organization with over 60,000 employees and uncovered a substantial number of inefficiencies, highlighting its practical value in real-world scenarios.
...
More than three decades after its introduction, Role-Based Access Control (RBAC) continues to be one of the most widely used access control models in organizations. This popularity stems from its simplicity, the reduced risk of errors, and its clear alignment with business processes. However, the primarily manual nature of data management in RBAC systems, coupled with a lack of oversight, can lead to various inefficiencies over time. These may include roles that are not assigned to any users or roles that have identical sets of permissions. Such issues can slow down systems that rely on these data and, more critically, complicate auditing processes, increasing the risk of security gaps and compliance violations.In this paper, we present a taxonomy of inefficiencies that can arise in RBAC data over time and propose a framework for detecting these inefficiencies. We specifically focus on the most resource-intensive inefficiencies, namely roles that share the same or similar users or permissions. To address these issues, we propose three detection methods, including a custom algorithm we developed. We evaluate these methods using synthetic datasets, demonstrating that our algorithm significantly outperforms baseline approaches. Its efficiency allows us to identify these inefficiencies even on a standard laptop used by large organizations. Furthermore, we applied our framework to real RBAC data from a large organization with over 60,000 employees and uncovered a substantial number of inefficiencies, highlighting its practical value in real-world scenarios.
Conference paper
(2025)
-
Max van der Horst, Ricky Kho, Olga Gadyatskaya, Michel Mollema, Michel van Eeten, Yury Zhauniarovich
As ransomware attacks grow in frequency and complexity, accurate attribution is crucial. Victim organizations often feel compelled to pay ransom, but must first attribute the attack and conduct sanction screening to ensure the threat actor receiving the payment is not a sanctioned entity, avoiding severe legal and financial risks. This cyber threat actor attribution process typically relies on Indicators of Compromise (IoCs) matching known threat profiles. However, the emergence of the Ransomware-as-a-Service (RaaS) ecosystem and rebranding behavior complicate attribution for sanction screening. Our mixed-methods study, combining interviews with 20 experts with an analysis of ransomware incident reports, reveals significant challenges and limitations in the current attribution process. High-level IoCs, widely regarded as more reliable, lack the necessary specificity for accurate attribution, leading to potential risks of misattribution. Practitioners rely on lower-level IoCs, which provide clearer links to threat actors but are highly volatile, further complicating sanction enforcement. These challenges highlight the need for urgent improvements in the attribution and sanction processes. To mitigate these risks, we offer recommendations aimed at enhancing data-sharing practices, improving attributions frameworks, and refining the sanction violation policy to better support sanction screening efforts. While we do not recommend paying ransomware actors, we acknowledge that some organizations may face pressures to do so in certain situations. In such cases, it is vital to ensure legal compliance, particularly regarding sanctioned entities. This work aims to help victims of ransomware shield themselves from transgressing against sanctions.
...
As ransomware attacks grow in frequency and complexity, accurate attribution is crucial. Victim organizations often feel compelled to pay ransom, but must first attribute the attack and conduct sanction screening to ensure the threat actor receiving the payment is not a sanctioned entity, avoiding severe legal and financial risks. This cyber threat actor attribution process typically relies on Indicators of Compromise (IoCs) matching known threat profiles. However, the emergence of the Ransomware-as-a-Service (RaaS) ecosystem and rebranding behavior complicate attribution for sanction screening. Our mixed-methods study, combining interviews with 20 experts with an analysis of ransomware incident reports, reveals significant challenges and limitations in the current attribution process. High-level IoCs, widely regarded as more reliable, lack the necessary specificity for accurate attribution, leading to potential risks of misattribution. Practitioners rely on lower-level IoCs, which provide clearer links to threat actors but are highly volatile, further complicating sanction enforcement. These challenges highlight the need for urgent improvements in the attribution and sanction processes. To mitigate these risks, we offer recommendations aimed at enhancing data-sharing practices, improving attributions frameworks, and refining the sanction violation policy to better support sanction screening efforts. While we do not recommend paying ransomware actors, we acknowledge that some organizations may face pressures to do so in certain situations. In such cases, it is vital to ensure legal compliance, particularly regarding sanctioned entities. This work aims to help victims of ransomware shield themselves from transgressing against sanctions.
We Really Need the Help of AI
A Case Study of AI Adoption in Cybersecurity
We investigate the sociotechnical factors influencing the adoption of AI-based tools in cybersecurity operations within a large international financial organization, using a reflexive thematic analysis grounded in a Sociotechnical Systems (STS) framework. Our qualitative case study involved 15 interviews with security analysts, data scientists, and departmental leaders to explore end-user perspectives, organizational culture, and technical constraints shaping AI adoption. Drawing on established models, we analyze barriers such as mistrust in AI systems, ineffective feedback mechanisms, lack of domain knowledge, and job security concerns. The study reveals a disconnect between the availability of AI tools and their actual use, primarily driven by human-centric resistance and structural inefficiencies rather than technical limitations. These findings emphasize the importance of aligning AI development with analysts’ workflows, increasing explainability, and making design processes more collaborative. We propose a targeted suite of interventions – including training, cross-functional mentorship, and enhanced feedback channels – to support the responsible and effective integration of AI. Our research contributes a theory-informed and empirically grounded understanding of AI adoption challenges in cybersecurity, with practical implications for organizations navigating the human-AI interface in corporate environments.
...
We investigate the sociotechnical factors influencing the adoption of AI-based tools in cybersecurity operations within a large international financial organization, using a reflexive thematic analysis grounded in a Sociotechnical Systems (STS) framework. Our qualitative case study involved 15 interviews with security analysts, data scientists, and departmental leaders to explore end-user perspectives, organizational culture, and technical constraints shaping AI adoption. Drawing on established models, we analyze barriers such as mistrust in AI systems, ineffective feedback mechanisms, lack of domain knowledge, and job security concerns. The study reveals a disconnect between the availability of AI tools and their actual use, primarily driven by human-centric resistance and structural inefficiencies rather than technical limitations. These findings emphasize the importance of aligning AI development with analysts’ workflows, increasing explainability, and making design processes more collaborative. We propose a targeted suite of interventions – including training, cross-functional mentorship, and enhanced feedback channels – to support the responsible and effective integration of AI. Our research contributes a theory-informed and empirically grounded understanding of AI adoption challenges in cybersecurity, with practical implications for organizations navigating the human-AI interface in corporate environments.
Journal article
(2024)
-
Hilmy Hanif, J.E. Constantino Torres, M.T. Sekwenz, M.J.G. van Eeten, J. Ubacht, Ben Wagner, Y. Zhauniarovich
The AI Act represents a significant legislative effort by the European Union to govern the use of AI systems according to different risk-related classes, imposing different degrees of compliance obligations to users and providers of AI systems. However, it is often critiqued due to the lack of general public comprehension and effectiveness regarding the classification of AI systems to the corresponding risk classes. To mitigate these shortcomings, we propose a Decision-Tree-based framework aimed at increasing legal compliance and classification clarity. By performing a quantitative evaluation, we show that our framework is especially beneficial to individuals without a legal background, allowing them to enhance the accuracy and speed of AI system classification according to the AI Act. The qualitative study results show that the framework is helpful to all participants, allowing them to justify intuitively made decisions and making the classification process clearer.
...
The AI Act represents a significant legislative effort by the European Union to govern the use of AI systems according to different risk-related classes, imposing different degrees of compliance obligations to users and providers of AI systems. However, it is often critiqued due to the lack of general public comprehension and effectiveness regarding the classification of AI systems to the corresponding risk classes. To mitigate these shortcomings, we propose a Decision-Tree-based framework aimed at increasing legal compliance and classification clarity. By performing a quantitative evaluation, we show that our framework is especially beneficial to individuals without a legal background, allowing them to enhance the accuracy and speed of AI system classification according to the AI Act. The qualitative study results show that the framework is helpful to all participants, allowing them to justify intuitively made decisions and making the classification process clearer.
Charting the Path to SBOM Adoption
A Business Stakeholder-Centric Approach
Organizations are increasingly reliant on third-party software products to expedite their own development cycles, often incorporating numerous components into their end systems, resulting in a lack of transparency in software dependencies. Malicious actors exploit this, leading to Software Supply Chain (SSC) attacks with substantial economic and security damages. To mitigate this threat, the Software Bill of Materials (SBOM) concept was introduced. It details software components and their supply chain relationships, thus enhancing SSC transparency. Unfortunately, SBOM adoption still remains limited. While previous studies identified some reasons behind this, they overlooked the perspectives of different business stakeholder groups involved in SBOM's lifecycle.
In this work, we address this gap by studying business stakeholder groups directly involved in SBOM production and consumption. The main goal of this work is to identify which groups can drive or inhibit SBOM adoption and the rationale behind this behavior. By conducting interviews with the group representatives, we identified stakeholder-specific risks, benefits, concerns and incentives regarding SBOM adoption. Our analysis suggests that SBOM adoption potential is higher among System Integrators and Software Vendors. At the same time, B2B customers and Individual Developers have the least motivation, inhibiting the process of SBOM adoption. Given that these are the main SBOM consuming and supplying stakeholders correspondingly, we conclude that the overall adoption potential of this technology is currently limited and requires considerable external impulse. ...
In this work, we address this gap by studying business stakeholder groups directly involved in SBOM production and consumption. The main goal of this work is to identify which groups can drive or inhibit SBOM adoption and the rationale behind this behavior. By conducting interviews with the group representatives, we identified stakeholder-specific risks, benefits, concerns and incentives regarding SBOM adoption. Our analysis suggests that SBOM adoption potential is higher among System Integrators and Software Vendors. At the same time, B2B customers and Individual Developers have the least motivation, inhibiting the process of SBOM adoption. Given that these are the main SBOM consuming and supplying stakeholders correspondingly, we conclude that the overall adoption potential of this technology is currently limited and requires considerable external impulse. ...
Organizations are increasingly reliant on third-party software products to expedite their own development cycles, often incorporating numerous components into their end systems, resulting in a lack of transparency in software dependencies. Malicious actors exploit this, leading to Software Supply Chain (SSC) attacks with substantial economic and security damages. To mitigate this threat, the Software Bill of Materials (SBOM) concept was introduced. It details software components and their supply chain relationships, thus enhancing SSC transparency. Unfortunately, SBOM adoption still remains limited. While previous studies identified some reasons behind this, they overlooked the perspectives of different business stakeholder groups involved in SBOM's lifecycle.
In this work, we address this gap by studying business stakeholder groups directly involved in SBOM production and consumption. The main goal of this work is to identify which groups can drive or inhibit SBOM adoption and the rationale behind this behavior. By conducting interviews with the group representatives, we identified stakeholder-specific risks, benefits, concerns and incentives regarding SBOM adoption. Our analysis suggests that SBOM adoption potential is higher among System Integrators and Software Vendors. At the same time, B2B customers and Individual Developers have the least motivation, inhibiting the process of SBOM adoption. Given that these are the main SBOM consuming and supplying stakeholders correspondingly, we conclude that the overall adoption potential of this technology is currently limited and requires considerable external impulse.
In this work, we address this gap by studying business stakeholder groups directly involved in SBOM production and consumption. The main goal of this work is to identify which groups can drive or inhibit SBOM adoption and the rationale behind this behavior. By conducting interviews with the group representatives, we identified stakeholder-specific risks, benefits, concerns and incentives regarding SBOM adoption. Our analysis suggests that SBOM adoption potential is higher among System Integrators and Software Vendors. At the same time, B2B customers and Individual Developers have the least motivation, inhibiting the process of SBOM adoption. Given that these are the main SBOM consuming and supplying stakeholders correspondingly, we conclude that the overall adoption potential of this technology is currently limited and requires considerable external impulse.
Finding Harmony in the Noise
Blending Security Alerts for Attack Detection
Conference paper
(2024)
-
Tom-Martijn Roelofs, Eduardo Barbaro, Svetlana Pekarskikh, Katarzyna Orzechowska, Marta Kwapień, Jakub Tyrlik, Dinu Smadu, Michel van Eeten, Yury Zhauniarovich
Large- and medium-sized organizations employ various security systems to protect their assets. These systems, often developed by different vendors, focus on different threats and usually work independently. They generate separate and voluminous alerts that have to be monitored and analyzed by often overburdened security analysts. Prior work has tried to support analysts by better correlating and prioritizing alerts. In this work, we propose to combine the wisdom of individual security systems using an Integration Layer (IL). We validated our idea by deploying the IL in a large global organization (50,000+ employees) running four very different security detection systems. We did so by using end-to-end red-team exercises to generate real attack data. For training, we labeled our dataset with evaluations directly from the incident response team instead of using the escalated decisions of the first/second tier Security Operation Center (SOC) analysts as in prior works. We showed that our approach considerably reduces the number of alerts requiring investigation while maintaining very high performance on multi-step attack detection - Matthews correlation coefficient (MCC) reaches 0.998. The substantial dependence of the model on features derived from the different security systems supports the viability of our integration methodology. The explainability layer added to our system gives analysts insights into why a particular case is marked as an attack or non-attack. Based on the test results, our approach has been added to the production setup.
...
Large- and medium-sized organizations employ various security systems to protect their assets. These systems, often developed by different vendors, focus on different threats and usually work independently. They generate separate and voluminous alerts that have to be monitored and analyzed by often overburdened security analysts. Prior work has tried to support analysts by better correlating and prioritizing alerts. In this work, we propose to combine the wisdom of individual security systems using an Integration Layer (IL). We validated our idea by deploying the IL in a large global organization (50,000+ employees) running four very different security detection systems. We did so by using end-to-end red-team exercises to generate real attack data. For training, we labeled our dataset with evaluations directly from the incident response team instead of using the escalated decisions of the first/second tier Security Operation Center (SOC) analysts as in prior works. We showed that our approach considerably reduces the number of alerts requiring investigation while maintaining very high performance on multi-step attack detection - Matthews correlation coefficient (MCC) reaches 0.998. The substantial dependence of the model on features derived from the different security systems supports the viability of our integration methodology. The explainability layer added to our system gives analysts insights into why a particular case is marked as an attack or non-attack. Based on the test results, our approach has been added to the production setup.
Conference paper
(2024)
-
Anne Kee Doing, Eduardo Barbaro, Frank van der Roest, Pieter van Gelder, Yury Zhauniarovich, Simon Parkin
A reduction in phishing threats is of increasing importance to organizations. One part of this effort is to provide training to employees, so that they are able to identify and avoid phishing emails. Yet further, simulated phishing emails are used to test whether employees will both identify and report a suspicious email. We worked with a partner bank to examine a repository of many thousands of reported emails from a behavioural perspective. We divide reported emails into categories and examine reporting trends over time relative to training and phishing simulation campaigns. Among our findings, the level of reporting of benign emails is comparable to the number of malicious emails reported, and we see indications that training and simulations amplify the reporting of benign emails. Our analysis uncovers reporting patterns for unique reporters per email campaign as a promising indicator for the security-related culture around phishing prevention. Evidence from our analysis informs recommendations, such as providing reporting infrastructure for reporting not only malicious emails, but also benign but suspicious work-related emails, in a manner that minimises the disruption for users erring on the side of caution when assessing emails.
...
A reduction in phishing threats is of increasing importance to organizations. One part of this effort is to provide training to employees, so that they are able to identify and avoid phishing emails. Yet further, simulated phishing emails are used to test whether employees will both identify and report a suspicious email. We worked with a partner bank to examine a repository of many thousands of reported emails from a behavioural perspective. We divide reported emails into categories and examine reporting trends over time relative to training and phishing simulation campaigns. Among our findings, the level of reporting of benign emails is comparable to the number of malicious emails reported, and we see indications that training and simulations amplify the reporting of benign emails. Our analysis uncovers reporting patterns for unique reporters per email campaign as a promising indicator for the security-related culture around phishing prevention. Evidence from our analysis informs recommendations, such as providing reporting infrastructure for reporting not only malicious emails, but also benign but suspicious work-related emails, in a manner that minimises the disruption for users erring on the side of caution when assessing emails.
Distributed Denial-of-Service (DDoS) attacks continue to threaten the availability of Internet-based services. While countermeasures exist to decrease the impact of these attacks, not all operators have the resources or knowledge to deploy them. Alternatively, anti-DDoS services such as DDoS clearing houses and blackholing have emerged. Unwanted Traffic Removal Service (UTRS), being one of the oldest community-based anti-DDoS services, has become a global free collaborative service that aims at mitigating major DDoS attacks through the Border Gateway Protocol (BGP). Once the BGP session with UTRS is established, UTRS members can advertise part of the prefixes belonging to their AS to UTRS. UTRS will forward them to all other participants, who, in turn, should start blocking traffic to the advertised IP addresses. In this paper, we develop and evaluate a methodology to automatically detect UTRS participation in the wild. To this end, we deploy a measurement infrastructure and devise a methodology to detect UTRS-based traffic blocking. Using this methodology, we conducted a longitudinal analysis of UTRS participants over ten weeks. Our results show that at any point in time, there were 562 participants, including multihomed, stub, transit, and IXP ASes. Moreover, we surveyed 245 network operators to understand why they would (not) join UTRS. Results show that threat and coping appraisal significantly influence the intention to participate in UTRS.
...
Distributed Denial-of-Service (DDoS) attacks continue to threaten the availability of Internet-based services. While countermeasures exist to decrease the impact of these attacks, not all operators have the resources or knowledge to deploy them. Alternatively, anti-DDoS services such as DDoS clearing houses and blackholing have emerged. Unwanted Traffic Removal Service (UTRS), being one of the oldest community-based anti-DDoS services, has become a global free collaborative service that aims at mitigating major DDoS attacks through the Border Gateway Protocol (BGP). Once the BGP session with UTRS is established, UTRS members can advertise part of the prefixes belonging to their AS to UTRS. UTRS will forward them to all other participants, who, in turn, should start blocking traffic to the advertised IP addresses. In this paper, we develop and evaluate a methodology to automatically detect UTRS participation in the wild. To this end, we deploy a measurement infrastructure and devise a methodology to detect UTRS-based traffic blocking. Using this methodology, we conducted a longitudinal analysis of UTRS participants over ten weeks. Our results show that at any point in time, there were 562 participants, including multihomed, stub, transit, and IXP ASes. Moreover, we surveyed 245 network operators to understand why they would (not) join UTRS. Results show that threat and coping appraisal significantly influence the intention to participate in UTRS.
Peering into the Darkness
The Use of UTRS in Combating DDoS Attacks
Conference paper
(2024)
-
Radu Anghel, Swaathi Vetrivel, Elsa Turcios Rodriguez, Kaichi Sameshima, Daisuke Makita, Katsunari Yoshioka, Carlos Gañán, Yury Zhauniarovich
Remotely Triggered Black Hole (RTBH) is a common DDoS mitigation approach that has been in use for the last two decades. Usually, it is implemented close to the attack victim in networks sharing some type of physical connectivity. The Unwanted Traffic Removal Service (UTRS) project offers a free, global, and relatively low-effort-to-join and operate RTBH alternative by removing the requirement of physical connectivity. Given these unique value propositions of UTRS, this paper aims to understand to what extent UTRS is adopted and used to mitigate DDoS attacks. To reach this goal, we collected two DDoS datasets describing amplification and Internet-of-Things-botnet-driven attacks and correlated them with the information from the third dataset containing blackholing requests propagated to the members of UTRS. Our findings suggest that, currently, just a small portion of UTRS members (approximately 10 % ) trigger mitigation attempts: out of 1200+ UTRS members, only 124 triggered blackholing events during our study. Among those, with high probability, 25 Autonomous Systems (ASes) reacted on AmpPot attacks mitigating 0.025 % of them globally or 1.03 % targeting UTRS members; 2 countered IoT-botnet-driven attacks alleviating 0.001 % of them globally or 0.06 % targeting UTRS members. This suggests that UTRS can be a useful tool in mitigating DDoS attacks, but it is not widely used.
...
Remotely Triggered Black Hole (RTBH) is a common DDoS mitigation approach that has been in use for the last two decades. Usually, it is implemented close to the attack victim in networks sharing some type of physical connectivity. The Unwanted Traffic Removal Service (UTRS) project offers a free, global, and relatively low-effort-to-join and operate RTBH alternative by removing the requirement of physical connectivity. Given these unique value propositions of UTRS, this paper aims to understand to what extent UTRS is adopted and used to mitigate DDoS attacks. To reach this goal, we collected two DDoS datasets describing amplification and Internet-of-Things-botnet-driven attacks and correlated them with the information from the third dataset containing blackholing requests propagated to the members of UTRS. Our findings suggest that, currently, just a small portion of UTRS members (approximately 10 % ) trigger mitigation attempts: out of 1200+ UTRS members, only 124 triggered blackholing events during our study. Among those, with high probability, 25 Autonomous Systems (ASes) reacted on AmpPot attacks mitigating 0.025 % of them globally or 1.03 % targeting UTRS members; 2 countered IoT-botnet-driven attacks alleviating 0.001 % of them globally or 0.06 % targeting UTRS members. This suggests that UTRS can be a useful tool in mitigating DDoS attacks, but it is not widely used.
The Unpatchables
Why Municipalities Persist in Running Vulnerable Hosts
Conference paper
(2024)
-
Aksel Ethembabaoglu, Rolf van Wegberg, Yury Zhauniarovich, Michel van Eeten
Many organizations continue to expose vulnerable systems for which patches exist, opening themselves up for cyberattacks. Local governments are found to be especially affected by this problem. Why are these systems not patched? Prior work relied on vulnerability scanning to observe unpatched systems, notification studies on remediating them, and on user studies of sysadmins to describe self-reported patching behavior, but they are rarely used together as we do in this study. We analyze scan data following standard industry practices and detect unpatched hosts across the set of 322 Dutch municipalities. Our first question is: Are these detections false positives? We engage with 29 security professionals working for 54 municipalities to collect ground truth.
All detections were accurate. Our approach also uncovers a major misalignment between systems that the responsible CERT attributes to the municipalities and the systems the practitioners at municipalities believe they are responsible for. We then interviewed the professionals as to why these vulnerable systems were still exposed. We identify four explanations for non-patching: unaware, unable, retired and shut down. The institutional framework to mitigate cyber threats assumes that vulnerable systems are first correctly identified, then correctly attributed and notified, and finally correctly mitigated. Our findings illustrate that the first assumption is correct, the second one is not and the third one is more complicated in practice. We end with reflections on how to better remediate vulnerable hosts. ...
All detections were accurate. Our approach also uncovers a major misalignment between systems that the responsible CERT attributes to the municipalities and the systems the practitioners at municipalities believe they are responsible for. We then interviewed the professionals as to why these vulnerable systems were still exposed. We identify four explanations for non-patching: unaware, unable, retired and shut down. The institutional framework to mitigate cyber threats assumes that vulnerable systems are first correctly identified, then correctly attributed and notified, and finally correctly mitigated. Our findings illustrate that the first assumption is correct, the second one is not and the third one is more complicated in practice. We end with reflections on how to better remediate vulnerable hosts. ...
Many organizations continue to expose vulnerable systems for which patches exist, opening themselves up for cyberattacks. Local governments are found to be especially affected by this problem. Why are these systems not patched? Prior work relied on vulnerability scanning to observe unpatched systems, notification studies on remediating them, and on user studies of sysadmins to describe self-reported patching behavior, but they are rarely used together as we do in this study. We analyze scan data following standard industry practices and detect unpatched hosts across the set of 322 Dutch municipalities. Our first question is: Are these detections false positives? We engage with 29 security professionals working for 54 municipalities to collect ground truth.
All detections were accurate. Our approach also uncovers a major misalignment between systems that the responsible CERT attributes to the municipalities and the systems the practitioners at municipalities believe they are responsible for. We then interviewed the professionals as to why these vulnerable systems were still exposed. We identify four explanations for non-patching: unaware, unable, retired and shut down. The institutional framework to mitigate cyber threats assumes that vulnerable systems are first correctly identified, then correctly attributed and notified, and finally correctly mitigated. Our findings illustrate that the first assumption is correct, the second one is not and the third one is more complicated in practice. We end with reflections on how to better remediate vulnerable hosts.
All detections were accurate. Our approach also uncovers a major misalignment between systems that the responsible CERT attributes to the municipalities and the systems the practitioners at municipalities believe they are responsible for. We then interviewed the professionals as to why these vulnerable systems were still exposed. We identify four explanations for non-patching: unaware, unable, retired and shut down. The institutional framework to mitigate cyber threats assumes that vulnerable systems are first correctly identified, then correctly attributed and notified, and finally correctly mitigated. Our findings illustrate that the first assumption is correct, the second one is not and the third one is more complicated in practice. We end with reflections on how to better remediate vulnerable hosts.