A Procedure for Vulnerability Analysis and Countermeasures in IoT Systems Based on Their Components Characteristics

Abstract

The increasing complexity and heterogeneity of Internet of Things (IoT) systems pose significant challenges for systematic security and vulnerability assessment. From a knowledge-centric perspective, IoT security analysis requires transforming heterogeneous asset information into structured and interpretable security knowledge. In this paper, we propose a structured methodology for vulnerability analysis that models the attack surface of an IoT system by explicitly linking asset characteristics to known vulnerabilities, security controls, and countermeasures. The approach starts with a visual representation of the system architecture, where hardware, software, and communication components are identified and described through their technical characteristics. These characteristics are automatically mapped to relevant vulnerabilities, security controls, and countermeasures using a dedicated software tool called AVCA (Asset Vulnerabilities and Countermeasures Analyzer). The tool generates graph-based analytical representations that model vulnerabilities–countermeasures relationships in compliance with the Cloud Security Alliance (CSA) IoT Security Framework. From these graphs, attack–countermeasure trees are derived to provide a clear and interpretable representation of potential threats and mitigation strategies. The proposed methodology was evaluated through a case study involving a representative IoT system and an exploratory applicability experiment with participants with different levels of experience in IoT and cybersecurity. The results suggest that the approach is feasible and practically applicable for supporting security analysts in the systematic assessment of IoT attack surfaces, vulnerability identification, and selection of appropriate countermeasures under the evaluated conditions. This work highlights the role of structured and interpretable knowledge extraction as a foundation for knowledge-centric and interpretable IoT security analysis.

1. Introduction

The Internet of Things (IoT) has a wide range of definitions. Kevin Ashton [1] was the first to use the term “Internet of Things (IoT)” to describe systems where the Internet is connected to the physical world via ubiquitous sensors. Over time, this concept has been refined and transformed. In [2], the IoT is defined as: “an open and comprehensive network of intelligent objects that have the capacity to auto-organize, share information, data and resources, reacting and acting in face of situations and changes in the environment.”

IoT is one of the fastest-growing technologies globally because it allows the development of a wide range of applications, such as autonomous vehicles, smart cities, environmental monitoring systems, and medical care [3]. Multiple investigations are being developed worldwide to explore the potential of IoT in a broad set of applications. However, IoT cybersecurity remains a challenging and evolving research area, requiring systematic and structured approaches tailored to its specific characteristics.

Just as there is a wide range of security risks and cyberattacks on the traditional Internet, IoT is also affected by cybercriminals who violate IoT systems [4]. However, due to the complexity and heterogeneity of the IoT systems’ components: sensors, actuators, controllers, gateways, communications protocols, applications, and others, IoT requires careful security analysis. It involves identifying each one of the components and characteristics of an IoT system to be able to perform a detailed security analysis to identify vulnerabilities and propose countermeasures to increase security.

As noted in [5], adversaries can exploit vulnerabilities in IoT devices, and such attacks may outweigh the potential benefits of their deployment. Conventional Internet protocols and security mechanisms are often inadequate for IoT environments, primarily due to their limited scalability, heterogeneous interoperability requirements, and the resource-constrained nature of IoT devices.

Currently, many vulnerability analysis tools for conventional systems do not work correctly with IoT systems due to the heterogeneity and interaction that IoT devices carry out differently with the physical world [6]. Therefore, conventional and IoT devices cannot be managed similarly.

Several frameworks for security analysis have been proposed; however, most are designed for conventional computing environments, and only a few offer a comprehensive perspective specifically tailored to IoT environments. IoT systems require specialized security solutions, as their large-scale and heterogeneous deployments significantly increase the complexity of information management and threat modeling [7].

Recently, visual representations of these systems have been proposed, given the difficulty of identifying assets in IoT systems. Examples include simple diagrams, from photographing the system, to a drawing with simple shapes representing the assets [8]. Others include standard formats like Unified Modeling Language (UML) [9]. However, such visual representations of IoT systems cannot capture all the characteristics that a device may possess, such as configurations, firmware updates, sensitive data, and other attributes, thereby omitting details that may be crucial for ensuring the security of both individual devices and the overall system.

From a Machine Learning and Knowledge Extraction (MAKE) perspective, the security analysis of IoT systems poses a knowledge-centric challenge rather than a purely algorithmic one. IoT environments generate heterogeneous, distributed, and partially structured information about assets, configurations, communication protocols, and operational behaviors. Transforming this heterogeneous information into structured, interpretable, and actionable security knowledge is a prerequisite for any systematic vulnerability analysis.

In this context, vulnerability assessment can be understood as a domain-specific knowledge extraction process, where raw asset characteristics are progressively transformed into higher-level security knowledge, including vulnerabilities, security controls, and countermeasures. This transformation requires explicit representations that support reasoning, traceability, and human interpretability, particularly in safety- and security-critical domains such as IoT.

Recent research frontiers in MAKE emphasize the importance of hybrid and modular approaches, interpretable representations, and knowledge-centric frameworks that bridge data, domain knowledge, and human understanding. Rather than relying exclusively on data-driven learning models, these approaches advocate for structured representations, graph-based reasoning, and transparent knowledge models that enable explainability and decision support. The methodology proposed in this work is aligned with this perspective by focusing on the systematic extraction, structuring, and visualization of security knowledge derived from IoT asset characteristics.

Within the research frontiers identified by Holzinger et al. [10], this work is primarily aligned with knowledge-centric and hybrid approaches to MAKE. In particular, it focuses on structured knowledge extraction, interpretable representations, and human-centered analysis. The proposed methodology emphasizes the transformation of heterogeneous IoT asset data into explicit, graph-based security knowledge, which can be directly inspected, traced, and reasoned about by human analysts.

More specifically, the vulnerabilities–countermeasure graphs and attack–countermeasure trees constitute graph-based analytical representations that support transparent reasoning and decision-making, rather than opaque predictive inference. It is important to clarify that the present work does not propose a predictive or data-driven machine learning model. Instead, it contributes to the Machine Learning and Knowledge Extraction (MAKE) field through a structured and interpretable knowledge extraction process. The methodology focuses on transforming heterogeneous IoT asset characteristics into explicit and traceable security knowledge representations. In this sense, the contribution is aligned with knowledge-centric and hybrid symbolic approaches that emphasize transparency, explainability, and human-centered reasoning.

The problem addressed in this work is the lack of specific tools for vulnerability analysis that support systematic knowledge extraction within frameworks explicitly designed for IoT and that consider device characteristics in areas such as hardware, software, and protocols to provide critical information for identifying and mitigating vulnerabilities. To address this gap, we propose a procedure for performing vulnerabilities and countermeasures analysis in IoT systems.

This proposal represents an initial approximation to a scheme in which the collection of information, analysis, and presentation of results are performed in a semi-automated manner. It can also be considered as a first step toward conducting other types of analyses within the same framework, such as risk analysis. However, this proposal should not be mistaken for a risk analysis, which involves identifying risks to a system’s security, determining their likelihood of occurrence, assessing the potential impact, and defining additional safeguards to mitigate that impact. Risk analysis forms part of risk management and is often used interchangeably with the term risk assessment. In contrast, vulnerability analysis is a systematic examination of an information system or product to evaluate the adequacy of existing security measures, identify deficiencies, generate data to predict the effectiveness of proposed security measures, and verify their adequacy after implementation.

The main contributions of this work are as follows:

• A knowledge-centric procedure for vulnerability analysis in IoT systems, which systematically extracts and structures security-relevant knowledge from heterogeneous asset characteristics within a well-defined security framework;
• A standardized and structured representation of IoT asset characteristics that enables consistent knowledge extraction, traceability, and reuse across vulnerability and countermeasure analyses;
• A semi-automated software tool, AVCA, that operationalizes the knowledge extraction process by linking asset-level characteristics to vulnerabilities and security controls, producing explicit and interpretable security knowledge models;
• A graph-based knowledge representation, in the form of vulnerabilities–countermeasures graphs and attack–countermeasure trees, that supports structured and interpretable knowledge extraction for IoT security analysis within a knowledge-centric MAKE perspective.

The remainder of this paper is organized as follows: Section 2 reviews the related works and the state of the art, comparing them with the proposed approach. Section 3 introduces the domains, subdomains, and characteristics considered, and details the vulnerability analysis process as well as the vulnerabilities–countermeasures graph and its nomenclature. Section 4 presents a case study along with the qualitative and quantitative evaluation of the proposal. Section 5 provides conclusions and outlines directions for future work. Finally, the Appendix A includes the questionnaires used in the evaluation and the user manual for the proposed AVCA (Asset Vulnerabilities and Countermeasures Analyzer) tool.

2. Related Works

This section reviews the most relevant and recent research that supports the proposed methodology and situates it within the current state of the art in IoT security analysis. The objective is twofold: first, to identify prominent approaches for vulnerability assessment, attack modeling, and mitigation in IoT systems published within the last five years; and second, to highlight the limitations that motivate the development of the proposed AVCA framework.

The reviewed works include survey papers, graph-based security models, automated vulnerability assessment tools, and visual modeling languages for IoT systems. Some of these contributions inspired specific components of the proposed methodology, while others were adopted conceptually to guide the overall design principles of the framework. Special attention is given to approaches that address scalability, automation, and interpretability, which are critical challenges in securing heterogeneous and large-scale IoT deployments.

Despite significant advances in IoT security research, existing approaches often focus on isolated aspects of the problem, such as attack detection, vulnerability classification, or risk estimation, without providing an integrated pipeline that systematically links asset characteristics, vulnerabilities, and countermeasures. This gap motivates the need for a unified, characteristic-driven, and graph-based framework capable of supporting both expert and non-expert analysts.

2.1. Recent Research

Recent research on IoT security has explored diverse approaches to vulnerability analysis and mitigation strategies, emphasizing the need for systematic and scalable methods to assess complex IoT ecosystems. For example, Hassan et al. [11] provide a comprehensive overview of IoT security architectures, attacks, and AI-based mitigation techniques, highlighting the role of machine learning in enhancing defensive capabilities across layers of IoT systems. Similarly, Pourranhmani et al. [12] categorize security vulnerabilities across IoT reference models and discuss countermeasures tailored to hardware, network, and application layers, offering a broad perspective on defensive needs.

Recent research has explored machine learning and artificial intelligence techniques for IoT cybersecurity, particularly in areas such as anomaly detection, intrusion detection systems (IDS), malware classification, and attack prediction. Data-driven approaches based on deep learning, ensemble methods, and graph neural networks have been proposed to automatically detect abnormal behavior patterns in IoT networks. These methods typically rely on large-scale datasets and statistical inference to identify threats.

In parallel, ontology-based and knowledge graph approaches have been developed to formally represent cybersecurity knowledge, including attack patterns, threat intelligence, and vulnerability taxonomies [13]. Structured knowledge bases such as MITRE ATT&CK provides systematic representations of adversarial tactics and techniques to support threat analysis and intelligence sharing [14]. Such approaches often employ semantic web technologies (e.g., RDF, OWL) or standardized knowledge exchange frameworks such as STIX and TAXII [15] to model relationships between assets, threats, and controls, enabling automated reasoning and semantic interoperability.

In contrast to predictive and ontology-driven frameworks, the present work focuses on structured, characteristic-driven knowledge extraction that supports traceability and interpretability within the vulnerability assessment process. The proposed vulnerabilities–countermeasures graph is not intended to be a formal semantic knowledge graph but rather a structured analytical representation designed to facilitate systematic reasoning about IoT attack surfaces.

Systematic reviews such as Fei et al. [16] have synthesized state-of-the-art research in IoT security, identifying prevalent research avenues and gaps that motivate automated and formalized vulnerability assessment frameworks. Coston [17] also surveys mitigation strategies with a focus on reducing attack surfaces and strengthening authentication and communication protocols, underscoring the persistent challenges in securing heterogeneous IoT deployments.

Graph-based modeling techniques have gained traction for representing security states and attach paths in IoT networks. Al-Araji et al. [18] propose attack graph-based security metrics that evaluate threat propagation and defense effectiveness, suggesting the utility of graph representations for security analysis. More recently, Lashkaripour et al. [19] introduce a Bayesian Security Aspect Graph (BSAGIoT) that models interdependencies among security aspects, enabling root cause analysis and quantitative risk assessment.

Practical vulnerability analysis methods have also been demonstrated in specific contexts, such as the work by Budiyanto et al. [20] which applies OWASP methodologies for vulnerability discovery in IoT networks, illustrating the need for automated tools to support comprehensive analysis.

While these studies contribute important insights into IoT security challenges and mitigation strategies, they typically do not provide a fully automated pipeline that maps asset characteristics to vulnerabilities and countermeasures within a unified graph-based model. In contrast, our proposed AVCA tool and methodology systematically generate vulnerability–countermeasure graphs from IoT system descriptions, offering a structured and scalable framework for security analysts to assess and mitigate vulnerabilities efficiently. Existing ML methods focus on detection/prediction, whereas our contribution is a knowledge extraction pipeline that yields interpretable, traceable artifacts usable as inputs to future ML.

2.2. Visual Language ViLanIoT

Recently, the visual language known as Visual Language for Internet of Things (ViLanIoT) was proposed and developed by Gomez-Cabrera et al. [21,22]. Its purpose is to customize visual elements and their associated grammar to represent the components, services, and protocols that comprise an IoT system, together with their cybersecurity properties. ViLanIoT assists analysts in identifying attack surfaces and vectors within IoT systems, making it a valuable tool for high-level security analysis. However, its visual nature imposes limitations: the diagrams cannot capture all the technical characteristics of IoT devices, such as configurations, updates, or sensitive data, that may be critical for a thorough vulnerability assessment. For this reason, in the present work ViLanIoT was adopted as the foundation for visual representation, but it is complemented with additional mechanisms to provide a more detailed and comprehensive security analysis.

Figure 1 illustrates the IoT personalized light switch system described in [8], which serves as a case study for security analysis. The figure presents a photograph of the physical system, annotated with key characteristics and the vulnerabilities identified, thereby providing a concrete basis for evaluating the proposed vulnerabilities–countermeasures framework. Figure 2 presents the visual diagram of the system from Figure 1, modeled using ViLanIoT. The diagram depicts the devices, connections, and communication protocols which are part of the IoT system.

This proposal enhances the capabilities of ViLanIoT, which generates a visual representation of IoT systems, by identifying their components, services, and protocols in use. In its current form, ViLanIoT depicts only the components and their most significant characteristics, as adding further elements would increase the complexity of the visual representation. To address this limitation, this work proposes the development of a vulnerabilities–countermeasures graph. This graph displays all the characteristics of each device, the vulnerabilities associated with those characteristics, and the countermeasures required to mitigate such vulnerabilities, thereby improving the security of every device within the system.

While ViLanIoT effectively represents structural components, services, and communication links, it does not explicitly encode configuration status, credential management conditions, firmware state, or derived vulnerabilities–countermeasures relationships. In contrast, the AVCA-generated artifacts transform these implicit properties into explicit, traceable security knowledge structures. For example, default credentials, open interfaces, or missing encryption modules are not visually differentiated in a standard ViLanIoT diagram but become explicit vulnerability nodes with associated countermeasures in the AVCA graph and attack–countermeasure tree.

2.3. Automatic Security Analysis of the Internet of Things

The Symbolic Hierarchical Automated Reliability and Performance Evaluator (SHARPE) tool [23] facilitates the automation of security analysis. Figure 3 presents a diagram illustrating the described process. This framework was tested on different IoT systems and based on the results it can identify the most vulnerable components and select defense mechanisms to mitigate potential attacks. Although the approach proposed provides a useful way to accelerate vulnerabilities assessment, its scope is limited to predefined scenarios and lacks the flexibility to incorporate the diverse characteristics of IoT devices, such as hardware constraints, software dependencies, and communication protocols. These limitations motivated the development of the vulnerability analysis process presented in this research, which builds upon the original idea while extending it to provide a more comprehensive and adaptable methodology for IoT security.

2.4. Hierarchical Attack Representation Model

In 2012, the Hierarchical Attack Representation Model (HARM) [24,25] was proposed to represent network information together with the associated vulnerabilities, organized into two distinct layers. The upper layer represents the network information, while the lower layer depicts the corresponding vulnerabilities. Figure 4 illustrates the presented HARM model.

The HARM model addresses the challenge of representing large-scale networks by managing extensive information about their components and the vulnerabilities of each element without losing clarity. This capability inspired the development of the vulnerabilities–countermeasures graph proposed in this work, as it similarly facilitates the handling of complex information while maintaining visibility of the components, vulnerabilities, and countermeasures involved. Although partly inspired by the HARM model, the proposed approach extends beyond it by incorporating not only system components and their vulnerabilities but also the specific characteristics of each asset and the corresponding countermeasures required to mitigate the identified vulnerabilities, thereby providing a more comprehensive and actionable security analysis.

Overall, the reviewed approaches demonstrate significant progress in IoT security analysis, ranging from survey-based classifications and automated assessment tools to graph-based and hierarchical attack modeling techniques. However, most existing works address individual aspects of the problem, such as vulnerability identification, attack propagation, or risk estimation, without providing an integrated mechanism that systematically links asset-level characteristics to vulnerabilities and explicit countermeasures.

In contrast, the methodology proposed in this work combines visual system modeling, characteristic-driven asset description, automated vulnerability and countermeasure association, and graph-based analysis within a unified framework. This positioning differentiates the proposed approach from related works and provides the basis for the comparative discussion presented in the Section 5, where the applicability and value of the framework are analyzed in relation to existing methods such as STRIDE, CORAS, and attack graph-based models.

3. Vulnerability Analysis Procedure

This section details the proposed procedure for vulnerabilities and countermeasures analysis, emphasizing the sequence of activities that structure its development and the key components that direct its operation. The description not only defines the procedural steps but also clarifies how each activity contributes to the overall objective of providing a systematic and comprehensive framework for assessing the security of IoT systems.

3.1. Selection and Identification of Assets’ Characteristics

This subsection defines the security domains and asset characteristics that constitute the foundation of the proposed vulnerability analysis procedure. The objective is to identify a concise yet comprehensive set of characteristics that adequately describe the security-relevant properties of IoT assets, enabling a systematic association with vulnerabilities and countermeasures.

The Cloud Security Alliance (CSA) IoT Security Framework [26] considers twenty security control domains with a set of sub-domains that encompass device properties, vulnerabilities, and mitigation mechanisms. However, not all the security control domains can be applied to the assets of an IoT system. Hence, in this work, eight of the twenty security control domains defined in the CSA IoT security framework are selected, as they are directly related to IoT systems and their core components. In addition, one complementary security control domain, Embedded Connections, is introduced by the authors to explicitly address asset-level security aspects that are not explicitly covered as a standalone domain in the CSA framework. Embedded connections play a critical role in shaping the attack surface of IoT systems, as vulnerabilities and threats may originate not only from the primary asset but also from tightly coupled external components. Although connectivity aspects are partially addressed across different domains of the CSA IoT Security Framework, this domain is added to enable a focused and systematic analysis of vulnerabilities and countermeasures arising from asset-to-asset embedded connections.

Therefore, a total of nine security control domains are considered in the proposed methodology. The description of each selected and proposed domain is given as follows:

• Asset Management: It involves the general characteristics of the asset, such as name, ID assignment, and control of the asset through inventories;
• Configuration Management: Contemplates everything related to hardware and software updates as well as the status of the general configuration of the asset;
• Secure Communications: It considers everything related to establishing secure communications at the level of networks and protocols used;
• Secure Data: Considers the management of the information that flows through the assets;
• Identity and Access Management: It contemplates everything related to the asset’s access credentials;
• IoT Device Security: It involves additional security aspects such as using certificates and security settings;
• Monitoring and Logging: considers the general monitoring part of the assets, both access and activities carried out on the asset;
• Secure Networks and Wireless: It involves the management of the wireless connections of the assets in case of having them;
• Embedded connections (Author-defined domain): This control domain is introduced to explicitly account for external assets that are directly connected to the asset under study, such as sensors, actuators, gateways, or peripheral devices.

According to several authors, the characteristics that should be considered for a security analysis are those related to the commercial part (the one that interests the user to buy the device) [26] as well as those that contemplate the operational part (the overall functionality of a device) [27]. Likewise, the analysis made by [28] considers the most common attacks on IoT devices, the vulnerabilities that these attacks imply, as well as the recommended countermeasures to mitigate such vulnerabilities. The CSA Security Framework [26] includes these characteristics and expands on them with vulnerabilities and countermeasures across twenty-one security domains. Every CSA sub-domain defines a set of characteristics that may be present in the assets of an IoT system. After reviewing the characteristics associated with the selected CSA security domains and considering hardware, software, communication protocols, and asset interconnections, the AVCA tool defines a set of asset characteristics and valid attributes used for automated vulnerability and countermeasure association. Listing 1 outlines each selected asset characteristic accompanied by a concise description. Together with each explanation are the corresponding valid attributes assigned to each characteristic. These attributes enable the AVCA tool to efficiently and effectively associate characteristics with appropriate security controls.

Listing 1. Description of the selected asset characteristics.

ID: The alphanumeric string to identify the asset. Valid attributes: Only the alphanumeric string that identifies the asset; Component’s Name: The asset’s name in the system; might be the exact ID string or another. Valid attributes: Only the alphanumeric string that contains the asset’s name; Type: The kind of asset. Valid attributes: sensor, actuator, or device; Energy Source: The source of power connected to the asset. Valid attributes: battery, alternating current, another device; Inventoried: If the asset is in an inventory system. Valid attributes: Yes, if the asset is in an inventory; No, if the asset is not in an inventory; Unknown, it is unknown if there exists an inventory; Firmware updates: The firmware must have the latest update. Valid attributes: Yes, if the asset has the latest update; No, if the asset has a different update; Default, if the asset has the factory firmware; Configuration status: The asset should be configured according to the user’s needs. Valid attributes: Yes, if the asset has a desired configuration; No, if the asset is configured differently; Default, if the asset has the factory configuration; Reached end-of-life: The asset should be at least within the warranty period established by the manufacturer. Valid attributes: Yes, if the asset is in the warranty period; No, if the asset is out of warranty; MQTT: The asset uses Message Queuing Telemetry Transport (MQTT) for communication. Valid attributes: Yes, No; Encryption module: The asset uses encryption. Valid attributes: Yes, if the asset uses encryption; No, if the asset does not use encryption; Unknown if it is not known if there is an encryption module; Trusted communications: The asset has trusted communication with other assets. Valid attributes: Yes; No; Unknown if it is not known if there is established trusted communications; Documented data: The data used by the asset is duly documented. Valid attributes: Yes, if data is documented; No, if data is not documented; Not apply if documenting data is considered unnecessary; Storage data encryption: The asset storage uses encryption. Valid attributes: Yes, if the asset uses storage encryption; No, if the asset does not use storage encryption; Not apply if storage data encryption is considered unnecessary; Data storage: The asset stores data. Valid attributes: Yes, no, Not apply, if storing data is considered unnecessary; Sensitive data: The data used by the asset is considered sensitive information. Valid attributes: Yes, if the asset uses sensitive data; No, if the asset does not use sensitive data; Not apply if data is not considered sensitive; Audit account: All accounts involved with the asset are duly managed. Valid attributes: Yes, No, Default, if the asset uses default credentials; Certificate-based authentication: The asset uses any certificate for authentication. Valid attributes: Yes, No, Not apply, if the asset does not need certificates; Root privileges: The asset has enabled high privileges. Valid attributes: Yes, No, Default, if the asset has the default privileges; Password management: All passwords involved with the asset are duly managed. Valid attributes: Yes, No, Unknown, if the asset uses generic passwords; Locked interfaces: All asset’s unused interfaces are closed or password-restricted. Valid attributes: Yes, No, Default, if the asset has open all interfaces; Password-locked test interfaces: All asset’s unused logical interfaces are closed or password-restricted. Valid attributes: Yes, No, Default, if the asset has open all test interfaces; Physical protection: The asset has anti-tampering or other physical protection. Valid attributes: Yes, No, Not apply, if the asset is in a considered secure environment; Logging registered: All logins to the asset are logged. Valid attributes: Yes, No, Unknown, if it is not known if there is any register; Monitored events: All the events in the asset should be monitored. Valid attributes: Yes, No, Unknown, if it is not known if there is any monitoring; Zig-Bee: The asset uses Zig-Bee for communication. Valid attributes: Yes, No; Wireless communications: The asset has wireless communication (mainly Wi-Fi and Bluetooth). Valid attributes: Yes, No, Unspecified, if the asset uses another wireless communication different from WiFi or Bluetooth; Embedded connections: The asset connects with other assets in the system. Valid attributes: String containing the connected asset’s ID.

Table 1. Selected domains, sub-domains, and their respective characteristics.

CSA Security Domain	CSA Sub-Domain	AVCA Asset Characteristic(s)	Role in AVCA
Asset Management	Naming Convention	ID, Component’s name, Type	Asset identification and classification
	Inventory Assets	Inventoried	Asset inventory status
	Monitor Assets	Energy source	Operational monitoring
Configuration Management	Configuration Files	Configuration status	Secure configuration assessment
	Firmware Updates	Firmware updates status	Firmware vulnerability assessment
	Configuration Control	Configuration status	Configuration integrity
	End-of-Life Planning	Reached end-of-life	Lifecycle risk evaluation
Secure communications	Trusted Communications	Trusted Communications	Trust relationship analysis
	MQTT Security	MQTT	Protocol-level exposure
	Encrypted Communications	Encryption module	Communication confidentiality
Secure data	Data Classification and Taxonomy	Documented data	Data governance assessment
	Data Cleansing	Sensitive data	Data sensitivity evaluation
	Encrypted Data at Rest	Data storage and Storage data encryption	Data protection at rest
Identity and access management	Password Mgmt	Password management	Credential security
	Authentication	Audit account	Authentication assessment
	Authorization	Audit account	Authorization control
	Access Control	Audit account	Access enforcement
	Certificate Mgmt	Certified-based authentication	Certificate usage
	Key Mgmt	Certified-based authentication	Key handling
	Trust Anchor Management	Not considered	Out of scope
	Bootstrap	Not considered	Out of scope
	Account Audit	Audit account	Account monitoring
IoT device security	Certified Devices	Certified-based authentication	Device trust
	Secure Platform	Physical protection	Physical security
	Secure Configuration	Root privileges, Locked interfaces, and Password-locked test interfaces	Device hardening
Monitoring and Logging	Threat Intelligence	Not considered	Out of scope
	Threat Hunting	Not considered	Out of scope
	Automated Malware Log Mgmt	Logging registered	Security logging
	Event Definition	Monitored events	Event monitoring
Secure networks and Wireless	Radio Frequency (RF) Monitoring	Wireless communications	Wireless exposure
	RF Architecture	Not considered	Out of scope
	Bluetooth Security	Wireless communications	Short-range wireless security
	Near Field Communication (NFC) Security	Not considered	Out of scope
	Zigbee Security	Zig-Bee	IoT-specific protocol security
Embedded connections	Embedded connections	Embedded connections	External asset attack surface

presents a consolidated and structured mapping between the selected CSA IoT security control domains, their corresponding sub-domains, and the asset characteristics employed by the AVCA tool. In addition, the table explicitly describes the functional role that each asset characteristic plays within the proposed methodology. This integrated representation clarifies how high-level CSA security concepts are operationalized into concrete, asset-level characteristics that can be systematically collected, processed, and analyzed. By associating each characteristic with a specific role, such as identification, configuration assessment, communication exposure, data protection, access control, monitoring, or physical security, the table provides a clear traceability path from asset description to vulnerability identification and countermeasure selection. Overall, Table 1 serves as a key reference that bridges the CSA IoT Security Framework and the AVCA analysis process, enabling consistent, repeatable, and interpretable vulnerability assessments.

Regarding the mobility of IoT components, the proposed methodology does not assume that assets are fixed or stationary. Instead, assets are modeled based on their technical characteristics, communication interfaces, configurations, and security-relevant properties, independently of their physical location. As a result, both fixed and mobile IoT components (e.g., wearable devices, mobile sensors, or embedded systems in vehicles) can be analyzed using the same procedure.

When mobility is relevant to the security analysis, it is implicitly captured through characteristics related to wireless communications, trusted connections, exposed interfaces, and embedded connections. This design choice allows the methodology to remain flexible and applicable to diverse IoT deployments without requiring location-specific modeling, while still enabling analysts to consider mobility-related attack surfaces when selecting characteristics and interpreting results.

Future extensions of the framework may incorporate hardware trust anchors and tamper-evident mechanisms, such as Physically Unclonable Functions (PUFs), secure elements, and hardware-based attestation models. Integrating such mechanisms into the characteristic-driven representation would further strengthen the end-to-end trust chain analysis of IoT deployments.

3.2. Vulnerabilities Analysis Procedure

It should be noted that this process is carried out semi-automatically. The characteristics of a given IoT device are collected manually by the system technician or with their assistance. These characteristics are stored in a standard JSON file, which is then processed by the AVCA tool. The tool automatically maps the characteristics to their associated vulnerabilities and countermeasures. It also generates a Comma-Separated Values (CSV) file containing the data for the vulnerabilities–countermeasures graph, which should be modeled using a graph visualization tool, preferably Gephi 0.9.6.

Although the current implementation relies on manual characterization assisted by a technician, the structured JSON-based input format enables straightforward integration with automated asset discovery tools, configuration management databases (CMDBs), software bill of materials (SBOM) parsers, and IoT monitoring platforms. In large-scale deployments, asset characteristics could be programmatically extracted from device management systems, firmware metadata, network scanning tools, or vulnerability scanners, thereby significantly reducing manual effort. Therefore, the proposed methodology should be understood as automation-ready rather than intrinsically manual.

To perform the vulnerabilities analysis of any IoT system, the process presented in Figure 5 is proposed; a detailed explanation of every step is described as follows:

• Select an implemented IoT system: Preferably, the IoT system analyzed should already be implemented, otherwise, the design phase must be finished.
• ViLanIoT representation: The previously selected IoT system must have a visual representation in a ViLanIoT diagram. If the ViLanIoT diagram is not available, make the respective visual representation.
• Make ViLanIoT representation: Follow the procedure for constructing a ViLanIoT diagram, explained in [21,29].
• Make a list of the IoT system’s assets: Identify every asset in the system that appears in the ViLanIoT diagram.
• Obtain characteristics and attributes of every asset: Identify the attributes that correspond to each characteristic described in the previous characteristics list, according to each asset’s particular conditions.
• Use AVCA tool: For more information on the use of the AVCA tool (v1.0), consult the user manual in the appendix described in [30] and in the GitHub repository https://github.com/pjorgeea/AVCAtool (accessed on 6 January 2026, see Supplementary Materials).
• Model the vulnerability and countermeasures graph: With the help of some graph modeling software, process the CSV file obtained from the AVCA tool. In this work, the use of Gephi [31] is recommended. An explanation of how modeling in this tool is also described in [30].
• Construct attack–countermeasure trees: They can be constructed based on the vulnerabilities–countermeasures graph. Follow the recommendations described in [32]. A general process on how to build an attack countermeasure tree is also presented in [30].

It is important to clarify that the proposed methodology does not assign explicit numerical priorities or weights to system components, devices, or services. Instead, prioritization is implicitly addressed through the selection of security domains, sub-domains, and asset characteristics considered in the analysis. These elements were chosen based on their relevance to IoT systems, as reported in recent literature and formalized by the CSA IoT Security Framework.

By focusing on domains related to asset management, configuration management, communications, data protection, identity and access management, device security, monitoring, networking, and embedded connections, the methodology emphasizes characteristics that have a direct impact on the attack surface of IoT assets. Characteristics and domains not directly affecting asset exposure or outside the scope of the analyzed system are intentionally excluded. This design choice ensures a systematic yet adaptable analysis, allowing analysts to focus on the most security-relevant aspects of IoT systems without introducing arbitrary weighting schemes.

3.3. Vulnerabilities–Countermeasures Graph

The vulnerabilities–countermeasures graph represents a core analytical artifact of the proposed methodology, as it provides a structured and visual representation of how asset characteristics, vulnerabilities, and mitigation actions are interrelated. This graph is automatically generated using the output produced by the AVCA tool, which delivers a comma-separated values (CSV) file containing the necessary information to model the graph through graph modeling software.

It is important to clarify that the vulnerabilities–countermeasures graph proposed in this work is not a formal ontology or a semantic web knowledge graph in the strict sense. The model does not rely on formal description logic, RDF/OWL encoding, or automated semantic reasoning. Instead, it constitutes a structured graph-based analytical representation aimed at ensuring traceability, interpretability, and systematic vulnerability mapping within the IoT security assessment workflow.

Figure 6 illustrates an instance of the vulnerabilities–countermeasures graph for a single IoT asset. The central node represents the analyzed asset and serves as the reference point for the entire structure. Surrounding this root node, the first concentric ring contains the asset characteristics identified during the characterization phase. Each characteristic is directly connected to the asset, establishing a clear relationship between the device and its defining properties.

The second concentric ring groups the vulnerabilities associated with each asset characteristic. These vulnerabilities are linked exclusively to the characteristic from which they originate, preserving traceability and enabling a precise understanding of how specific asset properties introduce security weaknesses. The identifiers displayed in this ring correspond to entries in the vulnerability analysis files generated by the AVCA tool, allowing analysts to cross-reference each vulnerability with detailed descriptions and supporting documentation.

The outer ring contains the countermeasures assigned to each identified vulnerability. Each vulnerability node is explicitly connected to its corresponding countermeasure(s), forming a one-to-one or one-to-many mapping that clearly indicates how specific mitigation actions address particular security weaknesses. This explicit linkage supports actionable security analysis by allowing analysts to move directly from vulnerability identification to mitigation planning.

From an analytical perspective, the vulnerabilities–countermeasures graph fulfills several key functions. First, it exposes the attack surface of an asset by aggregating all vulnerabilities derived from its characteristics in a single, coherent visual representation. Second, it integrates mitigation strategies directly into the analysis, ensuring that vulnerabilities are not considered in isolation but together with their corresponding countermeasures. Third, the visual complexity of the graph provides an intuitive indication of relative risk, as assets with a larger number of interconnected vulnerabilities and countermeasures typically exhibit a larger attack surface and, consequently, higher exposure to potential attacks.

Furthermore, the vulnerabilities–countermeasures graph serves as the foundation for constructing attack–countermeasure trees. By selecting specific vulnerabilities and countermeasures from the graph, analysts can model targeted attack scenarios and evaluate alternative mitigation paths, as will be described in Section 4. When the graphs of multiple assets are combined, it becomes possible to assess the overall attack surface of the entire IoT system, supporting system-level security analysis.

The nodes in the graph follow a consistent nomenclature that ensures traceability throughout the analysis pipeline. The root node represents the asset identifier. Nodes labeled as ChN denote asset characteristics, where N corresponds to the characteristic number. Vulnerability nodes are labeled as ChNVm, indicating vulnerability m associated with characteristic N. Countermeasure nodes are labeled as ChNVmCm, representing countermeasure Cm associated with vulnerability m of characteristic N. This nomenclature is not merely descriptive; it enables automated graph generation, consistent referencing across analysis artifacts, and seamless integration with subsequent attack modeling stages.

Overall, the vulnerabilities–countermeasures graph provides a scalable, interpretable, and actionable mechanism for visualizing IoT security conditions. By explicitly linking asset characteristics to vulnerabilities and countermeasures within a unified representation, the proposed approach supports systematic vulnerability assessment and informed decision-making for IoT security analysts.

To further clarify the logical structure encoded in the vulnerabilities–countermeasures graph, Listing 2 presents a simplified hierarchical representation of a single asset characteristic and its associated vulnerabilities and countermeasures. This textual view expresses the same relationships depicted in Figure 6, but in a linear and hierarchical form that facilitates analytical interpretation.

Listing 2. Hierarchical representation of a characteristic–vulnerabilities–countermeasures relationship.

Asset  └── Characteristic (Ch01)         ├── Vulnerability (Ch01V1)         │     └── Countermeasure (Ch01V1Cm1)         └── Vulnerability (Ch01V2)                └── Countermeasure (Ch01V2Cm1)

The representation highlights the parent–child relationships between the analyzed asset, its characteristics, the vulnerabilities derived from each characteristic, and the corresponding countermeasures. In particular, it illustrates the one-to-many relationship between an asset characteristic and its associated vulnerabilities, as well as the explicit one-to-one mapping between each vulnerability and its countermeasure.

This hierarchical view complements the concentric graphical representation by making the underlying structure of the model explicit, thereby improving readability and supporting subsequent security analysis tasks, such as the construction of attack–countermeasure trees. It also reinforces the traceability principle of the proposed methodology, as each node can be unambiguously linked to a specific asset characteristic, vulnerability, and mitigation action.

Although the current implementation does not assign explicit severity scores to vulnerabilities, the graph structure allows the incorporation of quantitative attributes such as CVSS scores, exploitability indices, or domain-specific risk weights. These attributes could be embedded as node properties and visually encoded through size, color, or filtering mechanisms, enabling prioritization without modifying the structural logic of the model.

In large-scale systems, the graph can be filtered by characteristic type, vulnerability category, or mitigation domain using standard graph-analysis tools (e.g., Gephi filtering mechanisms). Analysts may also extract subgraphs centered on specific high-risk characteristics or attack objectives. This modular filtering capability ensures that interpretability is maintained even as the number of nodes increases.

4. Case Study and Results

In this section, the procedure for obtaining the vulnerabilities–countermeasures graph and the attack countermeasure tree for any asset, given a visual representation of an IoT system, is described. The process begins with the graphical depiction of the IoT system, where each asset is uniquely identified by an ID. Once an asset is identified, the corresponding attributes associated with each characteristic, as defined in the previous section, are collected. Using the supporting software tool, a set of structured files is then generated. The vulnerabilities–countermeasures graph is produced by processing the CSV file generated by the AVCA software in a graph-modeling environment. Based on this graph, the attack countermeasure tree can subsequently be constructed, focusing on specific security targets or attack scenarios.

4.1. Case Study: Smart House IoT System

The system under consideration is designed to monitor and control the environmental conditions of a smart home. The example, originally presented in [33], consists of a FLIP device; a development board equipped with integrated sensors that measure temperature, humidity, air quality, light intensity, presence, and sound. A Raspberry Pi 3 functions as the gateway, enabling Internet connectivity and managing the data collected by the sensors. Additionally, the system includes a lamp connected to a relay, which allows remote switching operations for on/off control.

The system intends to control the environment of a smart home, such as lights, air conditioners, cameras, windows, doors, and appliances. Through the data collected from the sensors, the lighting, temperature, and humidity in the room are adjusted through an air conditioning system. It also aims to generate alerts and notifications about the status of the house. In Figure 7, the physical system is presented with all its components. In Figure 8, the same system is represented using ViLanIoT.

In this case, the vulnerabilities analysis is focused on the Raspberry Pi 3 because it acts as a gateway, and it is a component that can gather most of the characteristics previously described and serve as an example for a better visualization of the model, unlike other assets within the same system that can have very limited characteristics. The Raspberry Pi characteristics are collected in

Table 2. Raspberry Pi 3 characteristics.

Number	Characteristic	Attribute
1	ID	D03
2	Name	Raspberry Pi 3
3	Type	Device
4	Energy Source	Alternating current
5	Inventoried	No
6	Firmware update status	Default
7	Configuration status	Default
8	Reached end-of-life	No
9	MQTT	No
10	Encryption module	Unknown
11	Trusted communications	Unknown
12	Documented data	Unspecified
13	Storage data encryption	Unspecified
14	Data storage	Unspecified
15	Sensible data	No
16	Audit account	No
17	Certified-based authentication	Default
18	Root privileges	Default
19	Password management	Default
20	Locked interfaces	No
21	Password-locked test interfaces	No
22	Physical protection	No
23	Logging registered	No
24	Monitored events	Yes
25	Wireless communications	No
26	Zig-Bee	No
27	Embedded connections	D02

. Although the analysis can be carried out for each one of the assets of the IoT system, to exemplify the execution of the vulnerability analysis procedure, the selection of only one of the assets of the IoT system is made. The collection of characteristics along the case study was made by the author of this paper.

After using the AVCA software tool and processing the obtained CSV file in graph modeling software, the vulnerabilities–countermeasures graph is presented in Figure 9. In this graph, a set of thirty-five vulnerabilities and countermeasures can be observed. The notations in the nodes represent the notation defining the associated characteristics, vulnerabilities, and countermeasures as described in Section 3, and registered in the text files obtained from the AVCA tool. At first sight, it is observed that the asset has several areas of attention, such as configurations, data, password account management, and password-locked interfaces.

Figure 10 illustrates the attack countermeasure tree, which was constructed based on the vulnerabilities analysis performed. The model considers the exploitation of several vulnerabilities, such as inadequate physical protection, insufficient asset inventory, poor account management, and unsecured interfaces, to achieve the overall objective of disabling the operation of the Raspberry Pi device.

The attack countermeasures tree derived from the vulnerabilities–countermeasures graph provides a structured and hierarchical view of how potential attacks can be realized and mitigated within the analyzed IoT asset. Unlike a flat representation of vulnerabilities, the tree explicitly organizes security information in terms of attack objectives, intermediate attack steps, and corresponding countermeasures, allowing a clearer understanding of how vulnerabilities may be exploited in practice.

In the attack countermeasures tree, the root node denotes a high-level attack goal against the asset, while intermediate nodes represent vulnerabilities or attack paths that contribute to achieving that goal. Leaf nodes correspond to specific countermeasures that can be applied to disrupt or mitigate the attack progression. This structure enables security analysts to reason not only about the presence of vulnerabilities, but also about their role within broader attack scenarios and the effectiveness of available mitigation strategies.

By traversing the attack countermeasure tree from the root to the leaves, analysts can identify critical vulnerabilities whose mitigation would significantly reduce the attack surface of the asset. Conversely, the tree also highlights areas where multiple vulnerabilities converge on the same attack goal, indicating priority points for defense. As such, the attack countermeasure tree complements the vulnerabilities–countermeasures graph by transforming detailed security data into an interpretable decision-support model for IoT security assessment.

The identifiers in the attack countermeasure tree, shown in Figure 10, include:

• AMG (Attack Main Goal): Disable the operation of the Raspberry Pi;
• ASG-01 (Attack SubGoal): Alter the firmware/configuration files of the device;
• ASG-02 (Attack SubGoal): Initiate communication to Raspberry Pi from a foreign device;
• ASG-03 (Attack SubGoal): Connect USB with malware;
• ASG-04 (Attack SubGoal): Destroy the device with a physical attack;
• ASG-05 (Attack SubGoal): Choose an identifier for the intruding device;
• ASG-06 (Attack SubGoal): Choose credentials for login;
• AE-01 (Attack Event): Hitting any hard object;
• AE-02 (Attack Event): Generate an electric shock to the device;
• AE-03 (Attack Event): Duplicate an existing ID device;
• AE-04 (Attack Event): Invent any ID with any structure;
• AE-05 (Attack Event): Search for expired credentials;
• AE-06 (Attack Event): Create new credentials;
• AE-07 (Attack Event): Identify an open test interface;
• AE-08 (Attack Event): Identify an input/output interface opened;
• CoM-01 (Countermeasure): Deploy IoT devices that apply tamper protection for security-critical device components;
• CoM-02 (Countermeasure): Tamper protections range from simple seals and locked covers to piezo-electric circuits;
• CoM-03 (Countermeasure): Establish naming conventions for IoT devices and configure unique identifiers for each device;
• CoM-04 (Countermeasure): Develop a nomenclature for identifiers containing rules only the organization knows;
• CoM-05 (Countermeasure): Take action to disable any accounts that are determined as unnecessary, including those that are unauthorized and expired;
• CoM-06 (Countermeasure): Audit user, administrator, service, and device accounts within the IoT system at least annually;
• CoM-07 (Countermeasure): Disable or password-restrict any test interfaces;
• CoM-08 (Countermeasure): Disable or password-restrict any interfaces of general-purpose input/output.

Figure 10 presents the attack countermeasure tree derived from the vulnerabilities–countermeasures graph generated by the AVCA tool for a Raspberry Pi–based IoT asset. The tree provides a structured and hierarchical representation of how different attack paths may lead to the main attack objective and how corresponding countermeasures can mitigate these threats.

At the root of the tree is the Attack Main Goal (AMG), which in this case is disabling the operation of the Raspberry Pi. This objective can be achieved through several Attack SubGoals (ASGs) that represent alternative high-level strategies an adversary may follow. For example, ASG-01 focuses on altering firmware or configuration files, ASG-03 considers introducing malware via USB interfaces, and ASG-04 addresses direct physical destruction of the device. These subgoals are connected through logical AND/OR relationships, indicating whether attacks must be combined or can be executed independently.

Each Attack SubGoal is decomposed into one or more Attack Events (AEs) that describe concrete actions performed by an attacker. For instance, duplicating or inventing a device identifier (AE-03, AE-04), exploiting expired credentials (AE-05), or identifying open test or I/O interfaces (AE-07, AE-08). This decomposition allows analysts to understand how abstract attack strategies translate into actionable steps.

Finally, each Attack Event is associated with one or more Countermeasures (CoMs) that can prevent, detect, or mitigate the attack. Examples include enforcing strict naming conventions for device identifiers (CoM-03, CoM-04), disabling unused interfaces (CoM-07, CoM-08), auditing and managing credentials (CoM-05, CoM-06), and applying physical tamper protections (CoM-01, CoM-02). By explicitly linking attack events to countermeasures, the tree highlights how security controls can disrupt attack paths and reduce overall system risk.

Overall, the attack–countermeasure tree complements the vulnerabilities–countermeasures graph by providing an intuitive, decision-oriented view that supports risk analysis, prioritization of security controls, and systematic mitigation planning for IoT assets.

4.2. Proposal Applicability

Regarding the total number of characteristics, vulnerabilities, and countermeasures, these are counted in 27 characteristics, 59 vulnerabilities and countermeasures.

It was determined that the activity would be carried out by seven people with different profiles, from those who do not know about IoT systems and cybersecurity to those who have both profiles. Participants must replicate the procedure described in this paper; that is, given the visual representation of study cases, the participants collect the characteristics of a component of an IoT system, make use of the AVCA tool, and, based on the results obtained, generate the vulnerabilities–countermeasures graph and an attacks countermeasure tree. The data of the participants are presented in

Table 3. Participants’ Background Information.

Number	IoT Background	Cyber Security Background
1	No	No
2	No	No
3	Yes	No
4	No	No
5	No	Yes
6	Yes	Yes
7	Yes	Yes

.

The participants answered two questionnaires (presented in the Appendix A of this paper). In the first questionnaire, participants evaluated the difficulty of the overall procedure and each individual task on a scale from 1 to 5, where 1 indicated “very easy” and 5 indicated “very hard.” Figure 11 presents a graphic where the difficulty level perceived by each participant is displayed. This information comes from the results of questionnaire 1: General and particular difficulty of the process.

In the graph, it is observed that the procedure in general is considered intermediate between easy and hard, but some tasks like collecting data, using the software, and modeling the attack countermeasure tree were considered too hard.

For qualitative analysis of the experiment, the participants answered the second questionnaire named “General perception about the procedure.” It consists of seven questions. The results of this questionnaire are shown in Figure 12, Figure 13, Figure 14, Figure 15, Figure 16, Figure 17 and Figure 18. A brief explanation is provided below for each figure.

In the first question, see Figure 12, four participants considered the explanation of the procedure as clear, and the rest considered it unclear. The procedure in general was perceived as half clear.

For the second question, see Figure 13, five participants considered that training in IoT and cybersecurity was necessary. Just one participant considered training in IoT systems was necessary, and another one considered that only training in cybersecurity was necessary.

For the third question, see Figure 14, five participants have never implemented an IoT system, and only two participants have implemented at least one IoT system.

For the fourth question, see Figure 15, six participants considered that asking for information from the administrator and looking for a datasheet was the best way to collect information. Only one participant considered that it is better to ask for information only from the administrator.

For the fifth question, see Figure 16, six participants considered that the AVCA software tool was easy to use, and only one participant considered that it was difficult.

For the sixth question, see Figure 17, five participants observed only the vulnerabilities and countermeasures in the device within the graph. Two participants noticed the relationship between vulnerabilities and countermeasures, and only one participant identified the attack surface represented in the vulnerabilities and countermeasures graph.

For the seventh question, see Figure 18, all the participants answered that they did not have previous knowledge about attack–countermeasure trees.

The evaluation conducted in this study should be interpreted as an exploratory applicability and usability assessment rather than a statistically powered validation study. The number of participants (n = 7) does not allow inferential statistical analysis or generalizable conclusions. Instead, the objective of the experiment was to assess feasibility, clarity of the procedure, and perceived usability of the AVCA tool.

The questionnaire design was primarily descriptive and did not include reverse-coded items, control conditions, or counterfactual scenarios. While the results provide useful qualitative and descriptive quantitative insights, future work may incorporate larger samples and more rigorous statistical methodologies for Likert-scale analysis.

Despite these limitations, the experiment provides preliminary evidence of feasibility and perceived usability under the evaluated conditions.

5. Conclusions

5.1. Summary of Contributions and Main Findings

This work presented a systematic and tool-supported procedure for analyzing vulnerabilities and countermeasures in Internet of Things (IoT) systems based on asset characteristics. The proposed approach relies on a well-defined security framework that explicitly links asset characteristics, vulnerabilities, and countermeasures in order to obtain meaningful and interpretable security assessment results. In this study, the Cloud Security Alliance (CSA) IoT Security Framework was selected due to its comprehensive coverage and strong alignment with IoT-specific commercial and operational characteristics.

A key contribution of this work is the definition of a structured set of asset characteristics associated with well-defined attributes, which enables the AVCA tool to automatically map asset information to relevant security control domains, vulnerabilities, and countermeasures. This standardized representation significantly improves the efficiency and consistency of the analysis process. While the standardized input file is currently generated manually, the results indicate that future automation of this step is feasible and would further enhance usability.

The AVCA tool effectively bridges the gap between raw asset characterization and graphical security analysis by automating the construction of vulnerabilities–countermeasures graphs and attack–countermeasure trees. These graphical representations provide an intuitive and comprehensive view of the attack surface of IoT assets, even when multiple characteristics, vulnerabilities, and countermeasures coexist. Feedback from the applicability experiment highlighted that participants could visually assess the relative risk of an asset, where a larger and more complex graph often indicates a higher likelihood of successful exploitation.

The experimental evaluation suggests that users from diverse professional backgrounds were able to successfully apply the proposed procedure. Even participants with limited prior experience in IoT and cybersecurity were able to complete the analysis when guided through the structured procedure. This suggests that the framework can support non-expert users under supervised or assisted conditions, although domain knowledge remains beneficial for optimal interpretation.

From a Machine Learning and Knowledge Extraction perspective, this work contributes a knowledge-centric approach to IoT security analysis, emphasizing the extraction, structuring, and interpretation of security knowledge rather than predictive modeling. The proposed methodology demonstrates how heterogeneous IoT asset information can be transformed into explicit vulnerability–countermeasure knowledge using structured representations and graph-based models.

While the approach does not rely on data-driven machine learning algorithms, it aligns with contemporary MAKE research frontiers by adopting hybrid and interpretable knowledge representations that support transparency, traceability, and human-centered analysis. The vulnerabilities–countermeasures graphs and attack–countermeasure trees provide an explicit reasoning structure that enables analysts to understand and justify security decisions.

5.2. Applicability, Value, and Comparison with Related Approaches

Beyond its technical contributions, the proposed framework provides clear practical value for IoT security assessment. Unlike traditional vulnerability assessment approaches that rely heavily on expert-driven checklists or manual threat modeling, the AVCA-based methodology offers a semi-automated, repeatable, and visually guided process. This makes it particularly suitable for organizations where specialized cybersecurity expertise may be limited or distributed across multidisciplinary teams. Besides, the automation-ready design of the JSON-based asset characterization enables future integration with automated asset discovery mechanisms, supporting scalability in large IoT deployments.

Compared with existing approaches such as STRIDE-based threat modeling [34] or CORAS risk modeling [35], which focus primarily on identifying threats and risks at a conceptual level, the proposed framework emphasizes the explicit linkage between asset-level characteristics, concrete vulnerabilities, and actionable countermeasures. This characteristic-driven perspective allows analysts to trace how specific design or configuration decisions directly influence the security posture of an IoT asset. Furthermore, while many existing tools focus either on vulnerability scanning or risk estimation, the AVCA tool integrates characterization, vulnerability identification, and mitigation planning within a unified workflow.

The applicability experiment also revealed that optimal results are achieved when interdisciplinary collaboration is encouraged. Specifically, combining expertise in IoT technologies and cybersecurity leads to more accurate characterization of assets and richer attack countermeasure tree modeling. This finding reinforces the suitability of the framework for collaborative security assessments in real-world settings.

From a MAKE perspective, this work contributes primarily to structured and interpretable knowledge extraction in cybersecurity rather than to predictive machine learning. The framework establishes a formalized representation of IoT security knowledge that may serve as a foundation for future hybrid symbolic–statistical extensions, such as automated vulnerability prioritization or ML-based risk estimation models.

As future work, this research lays the foundation for incorporating quantitative risk analysis based on the generated graphs and trees. Well-established methodologies such as STRIDE and CORAS could be adapted to operate on top of the AVCA outputs, enabling a complete end-to-end risk assessment process. This extension would further strengthen the applicability of the framework and position it as a comprehensive solution for IoT security analysis and decision support.

Future work will also explore the integration of data-driven learning techniques, such as graph-based learning and hybrid symbolic–statistical methods, to further automate and enhance the knowledge extraction process. In this way, the proposed framework establishes a foundation for bridging IoT security analysis with emerging Machine Learning and Knowledge Extraction methodologies. This positioning highlights the role of structured and interpretable knowledge extraction as a key enabler for future intelligent IoT security analysis.