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

Round 1

Reviewer 1 Report (New Reviewer)

Comments and Suggestions for Authors

The manuscript addresses an interesting and relevant topic and presents a structured approach and supporting tool for modelling IoT cybersecurity vulnerabilities and countermeasures. However, several aspects need to be strengthened to meet the expected level of rigor for this journal.

1. Positioning within Machine Learning and AI
   The current manuscript contains only limited application of machine learning or data-driven methods. The contribution is primarily procedural and graph-based. Either the paper should incorporate more substantive machine learning or data science elements, or the claims regarding AI/ML should be moderated and the positioning clarified.

2. Knowledge Representation and Graph Modelling
   The proposed graph model is useful but should not be overstated as a full knowledge graph or formal knowledge representation framework. Please clarify the conceptual level of the model and, if appropriate, strengthen the discussion with references to relevant work on knowledge graphs, ontologies, and knowledge representation in cybersecurity and IoT contexts.

3. Related Work and Theoretical Context
   The literature review should be expanded to better cover:

   • applications of machine learning and AI in cybersecurity and IoT security,

   • knowledge graphs and ontology-based approaches to cybersecurity,

   • related data science and knowledge extraction methods.
     This will help position the contribution more clearly within the MAKE journal scope.

4. Empirical Evaluation and Questionnaire Design
   The evaluation based on the questionnaire and case study should be strengthened. The design of the questionnaire could be improved (e.g., inclusion of reverse or control items, reverse items, counterfactuals, clearer structure), and the analysis should include more rigorous statistical treatment where appropriate (see the literature on the meticulous analysis of Likert questionnaires). The current descriptive analysis is insufficient to support stronger claims about effectiveness.

5. Clarification of Contribution and Claims
   Please ensure that the claims made about the method and its capabilities are aligned with the evidence provided. Where the work represents an initial or conceptual step, this should be stated clearly and consistently.

Author Response

Response to reviewer 1

Dear Reviewer,

We sincerely thank you for your careful reading of our manuscript. Your observations have significantly helped us improve the clarity, positioning, and rigor of the manuscript. Below, we provide a detailed point-by-point response and describe the revisions made in the updated version.

Comment 1. Positioning within Machine Learning and AI

The current manuscript contains only limited application of machine learning or data-driven methods. The contribution is primarily procedural and graph-based. Either the paper should incorporate more substantive machine learning or data science elements, or the claims regarding AI/ML should be moderated and the positioning clarified.

Response

We appreciate this important observation and agree that the contribution of the manuscript is primarily knowledge-centric rather than data-driven machine learning.

In the revised version, we have:

1. Clarified that the proposed methodology does not implement predictive or statistical machine learning models.
2. Explicitly positioned the work within the knowledge-centric and hybrid symbolic paradigms of the Machine Learning and Knowledge Extraction (MAKE) perspective, emphasizing structured knowledge extraction and interpretability.
3. Moderated claims that could be interpreted as suggesting a data-driven AI contribution.

We now explicitly state in the Introduction and Conclusions that:

• The contribution lies in structured and interpretable knowledge extraction.
• The methodology focuses on transforming heterogeneous IoT asset characteristics into explicit and traceable security knowledge representations.
• The work may serve as a foundation for future hybrid symbolic–statistical extensions, but does not itself implement predictive ML.

These revisions ensure conceptual alignment with the MAKE journal scope while avoiding overstatement of AI/ML claims.

 

Comment 2. Knowledge Representation and Graph Modelling

The proposed graph model is useful but should not be overstated as a full knowledge graph or formal knowledge representation framework. Please clarify the conceptual level of the model and, if appropriate, strengthen the discussion with references to relevant work on knowledge graphs, ontologies, and knowledge representation in cybersecurity and IoT context.

Response

We thank the reviewer for this valuable clarification. In the revised manuscript, we have:

1. Explicitly clarified that the vulnerabilities–countermeasures graph is not a formal ontology-based or semantic web knowledge graph (e.g., OWL/RDF-based).
2. Stated clearly that the model is a structured graph-based analytical representation designed for interpretability and traceability, rather than a formal logical knowledge representation framework.
3. Added discussion distinguishing our approach from ontology-driven and semantic cybersecurity knowledge graph approaches.

Additionally, we expanded the Related Work section to include references to:

• Ontology-based cybersecurity frameworks,
• Semantic modeling approaches,
• Knowledge graph applications in IoT security.

This clarification ensures that the conceptual scope of the proposed graph model is accurately described and not overstated.

 

Comment 3. Related Work and Theoretical Context

The literature review should be expanded to better cover applications of machine learning and AI in cybersecurity and IoT security, knowledge graphs and ontology-based approaches to cybersecurity, related data science and knowledge extraction methods. This will help position the contribution more clearly within the MAKE journal concept.

Response

We agree that strengthening the theoretical positioning enhances the manuscript. In the revised version, we have substantially expanded the Related Work section to include:

1. Machine learning and AI-based approaches for IoT cybersecurity, including:
   • Intrusion detection systems (IDS),
   • Anomaly detection,
   • Deep learning–based threat detection,
   • Graph-based learning approaches.
2. Ontology-based and knowledge graph approaches in cybersecurity.
3. Data-driven vulnerability detection and risk modeling methods.

We also explicitly differentiate our contribution from predictive and statistical ML approaches by emphasizing that our work focuses on structured and interpretable knowledge extraction rather than data-driven threat prediction.

This expanded discussion situates the manuscript more clearly within the MAKE journal scope and clarifies its unique contribution.

 

Comment 4. Empirical Evaluation and Questionnaire Design

The evaluation based on the questionnaire and case study should be strengthened. The design of the questionnaire could be improved (e.g., inclusion of reverse or control items, reverse items, counterfactuals, clearer structure), and the analysis should include more rigorous statistical treatment where appropriate (see the literature on the meticulous analysis of Likert questionnaires). The current descriptive analysis is insufficient to support stronger claims about effectiveness.

Response

We appreciate this important methodological observation. We acknowledge that the empirical evaluation constitutes an exploratory applicability and usability assessment rather than a statistically powered validation study.

Given the scope of the work and the constraints of the conducted experiment, it was not possible to redesign the questionnaire or perform additional experiments. However, in the revised manuscript we have:

1. Explicitly characterized the evaluation as an exploratory applicability study.
2. Clarified that the sample size (n = 7) does not allow inferential statistical conclusions.
3. Added a dedicated subsection on Evaluation Scope and Limitations, explicitly discussing:
   • Small sample size,
   • Absence of reverse-coded items,
   • Lack of control groups,
   • Descriptive nature of the statistical analysis.
4. Moderated claims regarding effectiveness and generalizability accordingly.

The intention of the evaluation was to assess feasibility, interpretability, and usability rather than to provide statistically generalizable validation. We now clearly state this in the manuscript.

We believe this clarification addresses the concern while maintaining methodological transparency.

 

Comment 5. Clarification of Contribution and Claims

Please ensure that the claims made about the method and its capabilities are aligned with the evidence provided. Where the work represents an initial or conceptual step, this should be stated clearly and consistently.

Response

We fully agree with this recommendation. In the revised manuscript, we have systematically reviewed and moderated statements that could be interpreted as overly strong claims. Specifically:

• Expressions such as “demonstrates effectiveness” have been replaced with “suggests feasibility” or “supports applicability under the evaluated conditions.”
• The framework is consistently described as a structured, semi-automated, and interpretable vulnerability analysis methodology.
• We explicitly state that the work represents an initial structured step toward knowledge-centric IoT security analysis, rather than a comprehensive or fully automated AI-driven solution.

These revisions ensure that all claims are aligned with the presented evidence and that the scope of the contribution is clearly and consistently communicated.

 

We sincerely thank the reviewer for the thoughtful and technically rigorous feedback. The revisions made in response to these comments have strengthened the manuscript’s clarity, methodological positioning, and practical relevance. We believe the revised version now provides a clearer articulation of its contributions within the knowledge-centric perspective of Machine Learning and Knowledge Extraction.

We appreciate your time and consideration.

 

Respectfully,

 

The Authors

Author Response File: Author Response.pdf

Reviewer 2 Report (New Reviewer)

Comments and Suggestions for Authors The paper presents a structured approach to IoT security by bridging the gap between abstract security frameworks and the real IoT hardware. The authors introduced the AVCA tool and the graph-based visualizations, which are contributions that move away from black-box analysis toward interpretable security knowledge.

Comment 1:
The AVCA tool is described as semi-automated, the actual knowledge extraction starts with a heavily manual process. Step 5  in the procedure requires a technician to manually identify 27 distinct characteristics and attributes for every asset. In a large-scale IoT deployment with hundreds of devices, this would become a massive bottleneck. The authors should discuss how this process could be automated. Without this, the scalability mentioned in the abstract is somewhat undermined.
Comment 2:
The results of experiment (Section 4.2) are concerning. While 6 out of 7 participants said the software was easy to use (Figure 16), the quantitative data in Figure 11 shows that using the software was actually rated as too hard or hard by several participants. If the procedure is considered half clear and the modeling is too hard,  the claim that the framework supports non-expert analysts (line 170) should be more clearly defined.

Comment 3:
The authors explicitly state it is not a risk analysis because it doesn't assess likelihood or impact. By treating all vulnerabilities as a flat list, a security analyst might be overwhelmed by the 35+ vulnerabilities identified for a single Raspberry Pi. The authors should map severity or criticality of vulnerabilities, because not all carry the same security weight.   Comment 4: The methodology focuses almost entirely on software and configuration, but it ignores the physical security of the hardware itself. In real-world IoT deployment, the entire security chain breaks if the device isn't tamper-resistant. The authors should discuss how their analysis accounts for physical integrity and how trust is maintained if a device is compromised. Looking into recent trust models and tamper-evident frameworks, such as using PUF would help bridge this gap and make the paper much more robust.

Comment 5:
The vulnerabilities-countermeasures graph (Figure 9) is intended to aid interpretability. As the number of characteristics grows, these concentric graphs risk becoming difficult to read. It would be helpful to explain how an analyst should filter this graph to find the most critical countermeasures.

Comment 6:
In Section 2, the authors contrast their work with SHARPE and ViLanIoT. They claim ViLanIoT cannot capture all technical characteristics, and since ViLanIoT is base, can you explicitly show a before and after comparison. What exactly did the AVCA-generated tree find that a standard ViLanIoT diagram missed? 

Author Response

Response to reviewer 2

Dear Reviewer,

We sincerely thank you for your careful reading of our manuscript and for your insightful and constructive comments. Your observations have significantly helped us clarify and strengthen the manuscript. Below we provide a detailed, point-by-point response to each comment and describe the corresponding modifications incorporated into the revised version of the paper.

 

Comment 1.

The AVCA tool is described as semi-automated, the actual knowledge extraction starts with a heavily manual process. Step 5 in the procedure requires a technician to manually identify 27 distinct characteristics and attributes for every asset. In a large-scale IoT deployment with hundreds of devices, this would become a massive bottleneck. The authors should discuss how this process could be automated. Without this, the scalability mentioned in the abstract is somewhat undermined.

Response

We appreciate this important observation. We agree that manual characterization may become a bottleneck in very large-scale IoT deployments. The current implementation adopts a semi-automated approach to ensure traceability, correctness, and interpretability during the knowledge extraction phase. However, the methodology itself is not intrinsically manual.

To address this concern, we have expanded Section 3.2 to explicitly clarify that the structured JSON-based input format is compatible with automated data acquisition mechanisms. In large-scale deployments, asset characteristics could be programmatically extracted from configuration management databases (CMDBs), software bills of materials (SBOMs), firmware metadata, network discovery tools, vulnerability scanners, and IoT device management platforms.

We have therefore clarified that the proposed framework should be understood as automation-ready rather than inherently manual. This addition strengthens the scalability argument while maintaining methodological transparency.

 

Comment 2.

The results of experiment (Section 4.2) are concerning. While6 out of 7 participants said the software was easy to use (Figure 16), the quantitative data in Figure 11 shows that using the software was actually rated as too hard or hard by several participants. If the procedure is considered half clear and the modeling is too hard, the claim that the framework supports non-expert analysts (line 170) should be more clearly defined.

Response

We thank the reviewer for this careful interpretation of the results. We agree that the findings require nuanced explanation. The applicability experiment was exploratory and descriptive rather than a statistically powered validation study. The apparent discrepancy reflects that some participants found the modeling task conceptually demanding, while still perceiving the AVCA software interface itself as usable once guided through the procedure.

To clarify this point, we refined the claim regarding non-expert analysts in Section 5.1. The manuscript now states that the framework supports users under guided or structured conditions, rather than implying that it replaces domain expertise. We emphasize that domain knowledge remains beneficial for optimal interpretation, but that the structured procedure facilitates systematic analysis even for users with limited prior experience.

This modification ensures that the claims are precise and consistent with the experimental evidence.

 

Comment 3.

The authors explicitly state it is not a risk analysis because it doesn't assess likelihood or impact. By treating all vulnerabilities as a flat list, a security analyst might be overwhelmed by the 35+ vulnerabilities identified for a single Raspberry Pi. The authors should map severity or criticality of vulnerabilities, because not all carry the same security weight.

Response

We appreciate this valuable suggestion. The current work focuses on structured vulnerability identification and traceable countermeasure mapping rather than quantitative risk prioritization. As explicitly stated in the manuscript, the proposal is not intended to perform full risk analysis (i.e., likelihood and impact estimation).

However, we agree that incorporating severity metrics would enhance practical prioritization. To address this, we have added a clarification in Section 3.3 explaining that quantitative attributes such as CVSS scores or domain-specific risk weights can be integrated as node properties within the vulnerabilities–countermeasures graph. These attributes could be visually encoded (e.g., via node size, color, or filtering mechanisms) without altering the structural logic of the framework.

This extension is now discussed as a natural evolution of the methodology and a direction for future enhancement.

 

Comment 4.

The methodology focuses almost entirely on software and configuration, but it ignores the physical security of the hardware itself. In real-world IoT deployment, the entire security chain breaks if the device isn't tamper-resistant. The authors should discuss how their analysis accounts for physical integrity and how trust is maintained if a device is compromised. Looking into recent trust models and tamper-evident frameworks, such as using PUF would help bridge this gap and make the paper much more robust.

Response

We thank the reviewer for highlighting this crucial aspect. Physical protection is already included in the structured asset characteristics under the IoT Device Security domain. However, we acknowledge that the discussion on hardware-level trust mechanisms could be strengthened.

Accordingly, we expanded Section 3.1 to clarify how physical integrity is incorporated into the analysis through explicit asset characteristics. We also added a discussion in Section 5.2 addressing emerging hardware trust anchors such as Physically Unclonable Functions (PUFs), secure elements, and hardware-based attestation models as promising extensions to reinforce end-to-end trust in IoT deployments.

These additions improve the completeness of the security chain perspective without altering the scope of the current experimental evaluation.

 

Comment 5.

The vulnerabilities-countermeasures graph (Figure 9) is intended to aid interpretability. As the number of characteristics grows, these concentric graphs risk becoming difficult to read. It would be helpful to explain how an analyst should filter this graph to find the most critical countermeasures.

Response

We agree that large graphs can become visually complex. The framework was designed to be used with standard graph analysis tools (e.g., Gephi), which support filtering, subgraph extraction, and modular visualization.

To clarify this, we expanded Section 3.3 to explain how analysts can filter graphs by characteristic category, vulnerability domain, mitigation type, or other attributes. Subgraphs centered on specific high-risk characteristics or attack objectives can be extracted to maintain interpretability even in larger systems.

This clarification strengthens the practical usability of the proposed visualization approach.

 

Comment 6.

In Section 2, the authors contrast their work with SHARPE and ViLanIoT. They claim ViLanIoT cannot capture all technical characteristics, and since ViLanIoT is base, can you explicitly show a before and after comparison. What exactly did the AVCA-generated tree find that a standard ViLanIoT diagram missed?

Response

We appreciate this request for clarification. While ViLanIoT provides a structural representation of IoT components, services, and communication links, it does not systematically encode configuration status, firmware state, credential exposure, or explicit vulnerability–countermeasure relationships.

We have therefore expanded Section 2.2 and clarified in Section 4 how AVCA extends ViLanIoT. Specifically, AVCA transforms implicit configuration and security properties into explicit vulnerability nodes linked to countermeasures. For example, default credentials, missing encryption modules, or exposed interfaces are not visually differentiated in a standard ViLanIoT diagram but become explicit and traceable vulnerability elements within the AVCA-generated vulnerabilities-countermeasures graph and attack–countermeasure tree.

This addition makes the comparative contribution clearer and more concrete.

 

We sincerely thank the reviewer for the thoughtful and technically rigorous feedback. The revisions made in response to these comments have strengthened the manuscript’s clarity, methodological positioning, and practical relevance. We believe the revised version now provides a clearer articulation of its contributions within the knowledge-centric perspective of Machine Learning and Knowledge Extraction.

We appreciate your time and consideration.

 

Respectfully,

 

The Authors

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report (New Reviewer)

Comments and Suggestions for Authors

The author's responses to the criticisms are acceptable. The paper has improved, and the realistic formulation of the results achieved is suitable.

Reviewer 2 Report (New Reviewer)

Comments and Suggestions for Authors

Accept in present form.

This manuscript is a resubmission of an earlier submission. The following is a list of the peer review reports and author responses from that submission.

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The work at hand presents a vulnerability assessment framework for IoT devices that is built and implemented upon the so called AVCA analyzer (Asset Vulnerability and Countermeasures Analyzer). Although that is a very promising and highly investigated field of study the authors need to amend several things in order to make their content adequate to reach the academic standards for publication, as follows:

• The abstract should be re-written in order to introduce the reader to the most important points of the paper under review.
• All the photos and diagrams should be redesigned and formatted in a descent and universal template (no photos, no diagrams of different sizes) because anything else denotes bad practice and low expertise.
• The related work section needs to get amended in older to review the most recent and prominent works on the same field of study of the last five years at least.
• In subsection 3.1 the authors denote that “In this work, eight of the twenty CSA security control domains are selected, which are directly related to IoT systems. The description of each domain selected is given as follows…”, however nine (09) are referenced to the list that follows.
• Table 1 should be redesigned to describe the included information in a more consistent way.
• Above that, both the CSA security control domains and the AVCA tool attributes should be include in a Table in order to be easier for the reader to follow the authors notion. Also, Table 2 should be merged with the abovementioned domains.
• The vulnerabilities- countermeasures graphs should be re-created because they are in a very low analysis that makes them impossible to get studied.
• The attack-countermeasures tree graph although adequate it should be supported by text and not only by the headlines with their explanation.
• Finally, conclusions should be divided into two subsections with the one denote a thorough discussion upon the proposed framework’s applicability and value. Any comparison with already published works would add extra value to the paper.

Considering all the above, my decision is Major Revision.

Comments on the Quality of English Language

As that comments submitted above. 

 

Author Response

Comments 1:  The abstract should be re-written in order to introduce the reader to the most important points of the paper under review.

Response: Thank you for this comment. The abstract has been fully rewritten to better introduce the reader to the most important aspects of the paper. In the revised version, we explicitly emphasize the motivation behind the work, namely the challenges posed by the complexity and heterogeneity of IoT systems for systematic vulnerability assessment. We also clarify the main contributions of the paper, including the proposed structured methodology, the role of asset characteristics, and the use of the AVCA tool to automatically associate vulnerabilities, security controls, and countermeasures following the CSA IoT Security Framework. In addition, the abstract now highlights the generation of vulnerabilities–countermeasures graphs and attack–countermeasure trees, as well as the validation of the approach through a representative IoT case study and an applicability experiment. These changes improve clarity and provide a concise yet comprehensive overview of the methodology, results, and practical relevance of the proposed approach.

Comments 2: All the photos and diagrams should be redesigned and formatted in a descent and universal template (no photos, no diagrams of different sizes) because anything else denotes bad practice and low expertise.

Response: Thank you for this valuable comment regarding the presentation quality of the figures and diagrams. We fully agree that a consistent and clear visual presentation is essential for readability and good scientific practice.

In the revised version of the manuscript, all figures have been carefully redesigned and reformatted using a uniform and consistent template. Photographs and diagrams were adjusted to ensure homogeneous styling, resolution, and alignment across the paper. In particular, figure sizes were standardized as much as possible to maintain visual coherence.

For diagrams conveying complex system architectures or detailed graph structures, slightly larger formats were intentionally preserved to improve legibility and avoid information loss. This decision was made to ensure that all labels, connections, and structural elements remain clearly readable without compromising the consistency of the overall layout.

We believe that these revisions significantly improve the clarity, visual quality, and professional presentation of the manuscript, in line with the reviewer’s recommendation and the journal’s standards.

Comments 3: The related work section needs to get amended in older to review the most recent and prominent works on the same field of study of the last five years at least.

Response: We thank the reviewer for this important observation. We agree that a comprehensive and up-to-date review of recent and prominent research is essential to properly position the contribution of the paper.

In the revised manuscript, the Related Work section has been substantially expanded and updated to include relevant and recent studies published within the last five years. In particular, we have incorporated recent survey and review works that analyze IoT security architectures, vulnerabilities, and mitigation strategies, as well as research contributions focusing on systematic vulnerability assessment and countermeasure analysis. These include recent works addressing IoT security challenges and defensive mechanisms across different layers of IoT systems, as well as studies highlighting the need for automated and structured security assessment approaches.

Furthermore, we have added and discussed recent graph-based security modeling approaches for IoT systems, including attack graph and security graph methodologies, which are closely related to the vulnerability–countermeasure modeling proposed in this paper. Practical vulnerability analysis approaches based on established security frameworks have also been included to better contextualize the applied relevance of the proposed methodology.

The revised Related Work section now clearly contrasts these recent contributions with our approach, emphasizing how the proposed AVCA tool differs by providing an automated pipeline that maps asset characteristics to vulnerabilities and countermeasures within a unified graph-based framework aligned with the Cloud Security Alliance IoT Security Framework. We believe these additions significantly strengthen the contextualization and positioning of our work within the current state of the art.

Comments 4: In subsection 3.1 the authors denote that “In this work, eight of the twenty CSA security control domains are selected, which are directly related to IoT systems. The description of each domain selected is given as follows…”, however nine (09) are referenced to the list that follows.

Response: We thank the reviewer for highlighting this point, which allowed us to improve the clarity of Subsection 3.1.

In the proposed methodology, eight security control domains are directly selected from the Cloud Security Alliance (CSA) IoT Security Framework, as they are explicitly defined and directly applicable to IoT systems. In addition, a ninth control domain, named Embedded connections, is intentionally introduced by the authors. This additional domain is included to explicitly account for external assets that are directly connected to the asset under study, such as sensors, actuators, gateways, or peripheral devices, which significantly influence the security posture of IoT systems.

While the CSA framework considers connectivity aspects across multiple domains, it does not explicitly define a standalone domain that focuses on asset-to-asset embedded connections and their associated attack surface. The proposed Embedded connections domain addresses this gap by enabling the systematic identification of vulnerabilities and countermeasures arising from externally connected assets that are tightly coupled with the primary IoT component.

To avoid ambiguity, Subsection 3.1 has been revised to clearly state that a total of nine domains are considered: eight derived from the CSA framework and one complementary, author-defined domain. The text now explicitly distinguishes between CSA-defined domains and the additional Embedded connections domain, and clarifies the rationale for its inclusion.

We believe this revision improves the transparency and methodological rigor of the proposed approach.

Comments 5: Table 1 should be redesigned to describe the included information in a more consistent way. Above that, both the CSA security control domains and the AVCA tool attributes should be include in a Table in order to be easier for the reader to follow the authors notion. Also, Table 2 should be merged with the abovementioned domains.

Response: We thank the reviewer for this valuable suggestion. In the revised manuscript, Table 1 has been completely redesigned to provide a more consistent and integrated representation of the information. The revised table explicitly maps the selected CSA security control domains and sub-domains to the corresponding AVCA asset characteristics and their role within the proposed methodology.

In addition, the information previously presented in Table 2 has been merged into the revised Table 1 to avoid redundancy and to make the relationship between CSA domains and AVCA tool attributes easier to follow. The accompanying text has been updated accordingly to clearly introduce and explain this unified representation.

We believe that these changes significantly improve the clarity, consistency, and readability of the manuscript.

Comments 6: The vulnerabilities- countermeasures graphs should be re-created because they are in a very low analysis that makes them impossible to get studied.

Response: We thank the reviewer for this valuable comment and agree that vulnerability–countermeasure graphs must support effective analysis and interpretation.

In the revised manuscript, the vulnerability–countermeasure graphs have been redesigned to improve both readability and analytical clarity. The updated visualization adopts a structured concentric layout in which the central node represents the analyzed asset, the first ring corresponds to the asset’s characteristics, the second ring represents the associated vulnerabilities, and the third ring contains the corresponding countermeasures.

Furthermore, the connectivity has been refined so that each vulnerability node is linked only to its specific countermeasure(s), establishing an explicit one-to-one relationship between vulnerabilities and mitigation actions. This design choice reduces visual complexity while preserving the underlying analytical model, allowing readers to clearly trace security issues from asset characteristics through vulnerabilities to their corresponding countermeasures.

We believe that these improvements result in graphs that are both analytically meaningful and suitable for detailed study at publication resolution, while remaining faithful to the automated output of the proposed AVCA methodology.

Comments 7: The attack-countermeasures tree graph although adequate it should be supported by text and not only by the headlines with their explanation.

Response: We thank the reviewer for this valuable comment. We fully agree that the attack–countermeasures tree should be accompanied by an explicit and detailed textual explanation to facilitate its interpretation.

In the revised manuscript, we have substantially expanded the text in Section 4 to provide a comprehensive description of the attack–countermeasures tree. The new text explains the structure and semantics of the tree, including the role of the Attack Main Goal (AMG), Attack SubGoals (ASGs), Attack Events (AEs), and their associated Countermeasures (CoMs). The explanation clarifies how high-level attack objectives are decomposed into concrete attack actions and how each action is mitigated through specific countermeasures derived from the AVCA tool.

Additionally, the revised text explicitly guides the reader on how to interpret the logical relationships (AND/OR) between nodes and how the tree complements the vulnerabilities–countermeasures graph by offering a decision-oriented and risk-driven view of IoT security analysis.

These additions ensure that the figure is no longer self-contained but is now fully supported by explanatory text, improving clarity, readability, and analytical depth in accordance with the reviewer’s suggestion.

Comments 8: Finally, conclusions should be divided into two subsections with the one denote a thorough discussion upon the proposed framework’s applicability and value. Any comparison with already published works would add extra value to the paper.

Response: We thank the reviewer for this insightful and constructive comment. In response, the Conclusions section has been substantially revised and reorganized into two clearly differentiated subsections, Section 5.1 (Summary of Contributions and Main Findings) and Section 5.2 (Applicability, Value, and Comparison with Related Approaches).

In Section 5.1, we provide a concise synthesis of the main technical contributions and experimental findings of the paper, highlighting the role of the AVCA tool, the characteristic-driven analysis, and the resulting graphical models for IoT vulnerability and countermeasure assessment.

In Section 5.2, we present a detailed discussion of the applicability and practical value of the proposed framework, emphasizing its usability, accessibility, and suitability for real-world IoT security assessments. Additionally, this subsection now includes a qualitative comparison with well-established approaches such as STRIDE and CORAS, clarifying how the proposed methodology complements and extends existing threat and risk modeling techniques by explicitly linking asset characteristics, vulnerabilities, and countermeasures within a unified workflow.

These revisions directly address the reviewer’s suggestion by strengthening the interpretative depth of the Conclusions section and positioning the proposed framework within the broader context of existing research, thereby enhancing the overall contribution and impact of the paper.

Reviewer 2 Report

Comments and Suggestions for Authors

Reviewer #

This research presents a study to investigate and analyze the vulnerabilities of IoT technologies based on some characteristics of their components to explore appropriate security solutions. The authors focus on the communication protocols and interconnections between devices, as well as characteristics such as authentication mechanisms, data storage, and energy resources, to assess system vulnerabilities. This work introduces useful concepts. However, some concerns are addressed as follows:

In abstract:

1) Highlight the main issue in the research area caused by existing studies.

2) Explain why the study is important for the research field.

3) Stress the novelty of the systematic approach.

In introduction:

4) The section has been well-presented. However, use recent studies to address the existing challenges (problem definition) in the research area. The authors pointed out outdated references for the issue.

In related works:

5) The labels in Figure 1 are not clearly readable.

6) In Figure 4, is there a specific reason for depicting user 0 and root 2 in different colors? If so, please provide an explanation in the text or the figure caption.

In vulnerability analysis procedure:

7) Did the authors take into account the priority characteristic of the systems, devices, and services within IoT technology? If so, could you clarify which specific categories were addressed for the listed domains? If not, please explain the rationale behind this decision.

8) Did the authors consider the mobility features of the IoT components, or were they treated as fixed points?

In case study and results:

9) Figures 7 and 8 share the same caption; please provide distinct captions for each figure.

10) The x and y axes of the presented charts should be labeled with their corresponding features or parameters.

11) In Figures 12-18, I recommend presenting the questions in the text and using the charts to illustrate the responses. Additionally, please ensure that all axes are labeled. The authors may also consider using tables as an alternative to charts.

In conclusion:

12) Please conclude this section in one summary paragraph. 

Author Response

Comments 1:  In abstract:

1) Highlight the main issue in the research area caused by existing studies.

2) Explain why the study is important for the research field.

3) Stress the novelty of the systematic approach.

Response: Thank you for this comment. This observation has been addressed through a complete rewriting of the abstract, as also indicated in the response to Reviewer 1. In the revised abstract, the main issue in the research area is explicitly highlighted by emphasizing the challenges posed by the increasing complexity and heterogeneity of IoT systems and the lack of systematic, integrated approaches for vulnerability assessment in existing studies.

The importance of the study for the research field is clearly stated by positioning the proposed methodology as a practical and structured solution that supports security analysts in understanding IoT attack surfaces, vulnerabilities, and mitigation strategies in a unified manner.

Finally, the novelty of the proposed work is stressed by explicitly describing the systematic approach that links asset characteristics to vulnerabilities, security controls, and countermeasures through the AVCA tool, and by highlighting the automatic generation of vulnerabilities–countermeasures graphs and attack–countermeasure trees in compliance with the CSA IoT Security Framework. These elements collectively differentiate the proposed approach from prior work and underscore its contribution to the field.

Comments 2: In introduction:

4) The section has been well-presented. However, use recent studies to address the existing challenges (problem definition) in the research area. The authors pointed out outdated references for the issue.

Response: Thank you for this comment. This issue has already been addressed in the revised manuscript as part of the modifications introduced to respond to Reviewer 1. Specifically, the Introduction and the Related Works section were updated to incorporate recent and representative studies from the last five years that explicitly discuss current challenges in IoT security and vulnerability assessment.

The revised Introduction now grounds the problem definition in recent literature, highlighting contemporary issues such as the increasing heterogeneity and scale of IoT systems, the limitations of manual and ad hoc vulnerability assessment approaches, and the need for systematic and automated methodologies. These updates ensure that the motivation of the work is supported by up-to-date references and reflects the current state of research in the field.

As a result, the Introduction now provides a more accurate and timely characterization of the research challenges, while remaining fully aligned with the updated review of recent studies presented in Section 2.

Comments 3: In related works:

5) The labels in Figure 1 are not clearly readable.

6) In Figure 4, is there a specific reason for depicting user 0 and root 2 in different colors? If so, please provide an explanation in the text or the figure caption.

Response: Thank you for these observations. Both issues were addressed in the revised manuscript as part of the modifications introduced in response to Reviewer 1.

Regarding Figure 1, the figure was redesigned to improve readability. The resolution and layout were adjusted, and the labels were reformatted to ensure that all annotations are clearly legible and consistent in size and style. These changes improve the visual clarity of the figure and facilitate the interpretation of the system components and their associated characteristics.

Concerning Figure 4, the use of different colors to depict user 0 and root 2 reflects their distinct roles and privilege levels within the represented model. To avoid ambiguity, an explicit explanation has been added to the figure caption and accompanying text, clarifying that the color differentiation is used to visually distinguish between standard user entities and privileged/root entities. This clarification ensures that the visual encoding is meaningful and fully explained to the reader.

Comments 4: In vulnerability analysis procedure:

7) Did the authors take into account the priority characteristic of the systems, devices, and services within IoT technology? If so, could you clarify which specific categories were addressed for the listed domains? If not, please explain the rationale behind this decision.

Response: Thank you for this insightful comment. The proposed methodology does take prioritization into account, although not in the form of explicit numerical weights or rankings. Instead, prioritization is implicitly addressed through the structured selection of security domains, sub-domains, and asset characteristics considered in the analysis.

As described in the revised manuscript, the selected domains are those most directly related to the operational and commercial characteristics of IoT systems, as identified in the literature and formalized by the CSA IoT Security Framework. These include asset management, configuration management, secure communications, secure data handling, identity and access management, IoT device security, monitoring and logging, secure networks, and embedded connections. Domains and sub-domains that are not directly relevant to the analyzed system or that do not significantly impact the asset attack surface are explicitly marked as out of scope.

To clarify this design choice, an explanatory paragraph has been added to the vulnerability analysis procedure section, explaining that the methodology prioritizes security-relevant characteristics by design, rather than through predefined weighting schemes. This approach preserves flexibility and adaptability across different IoT deployments while maintaining a systematic and reproducible analysis process.

Comments 5: 8) Did the authors consider the mobility features of the IoT components, or were they treated as fixed points?

Response: Thank you for this comment. The proposed methodology does not assume IoT components to be fixed points. Instead, assets are modeled based on their technical and security-relevant characteristics, independently of their physical location or mobility. As such, both fixed and mobile IoT components can be analyzed using the same vulnerability analysis procedure.

Mobility-related aspects are implicitly captured through characteristics associated with wireless communications, trusted connections, exposed interfaces, and embedded connections, which are particularly relevant for mobile or dynamically connected devices. To clarify this design choice, an explanatory paragraph has been added to the vulnerability analysis procedure section, explicitly stating that the methodology is agnostic to asset mobility while remaining applicable to both stationary and mobile IoT deployments.

Comments 6: In case study and results:

9) Figures 7 and 8 share the same caption; please provide distinct captions for each figure.

Response: Thank you for pointing out this issue. The captions of Figures 7 and 8 have been revised to clearly distinguish the content and purpose of each figure. Figure 7 now describes the smart house IoT system from a physical and contextual perspective, while Figure 8 presents the same system modeled using the ViLanIoT visual language, showing the devices, connections, and communication protocols considered in the security analysis. These changes remove ambiguity and improve the clarity of the case study presentation.

Comments 7: 10) The x and y axes of the presented charts should be labeled with their corresponding features or parameters.

Response: We thank the reviewer for this observation. The x- and y-axis labels have been explicitly added to Figure 11 to improve clarity. The x-axis now denotes the study participants (P1–P7), while the y-axis represents the perceived difficulty level associated with each task evaluated during the applicability experiment. The figure caption has also been revised accordingly.

Comments 8: 11) In Figures 12-18, I recommend presenting the questions in the text and using the charts to illustrate the responses. Additionally, please ensure that all axes are labeled. The authors may also consider using tables as an alternative to charts.

Response: We thank the reviewer for this valuable suggestion. The manuscript has been revised accordingly. The questions associated with Figures 12–18 are now explicitly presented and discussed in the main text, while the charts are used exclusively to illustrate the distribution of participants’ responses. Each figure caption has been modified to clearly include the corresponding x- and y-axis labels.

Comments 9: In conclusion:

12) Please conclude this section in one summary paragraph. 

Response: We thank the reviewer for this comment. We acknowledge the suggestion of concluding the section with a single summary paragraph. However, in response to Reviewer 1’s recommendation, the Conclusions section was intentionally restructured into two clearly defined subsections.

The first subsection provides a comprehensive discussion of the applicability, practical value, and usability of the proposed AVCA framework, while the second subsection places the contribution in context through comparison with related and previously published works, as explicitly requested.

We believe that this two-part structure strengthens the clarity and completeness of the conclusions, allowing the reader to better distinguish between the discussion of the framework’s value and its positioning within the existing body of literature. For this reason, we have retained the current structure, which we consider more appropriate for the scope and contributions of the paper.

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

Although I am pleased with the amendments made by the authors. I believe that a final grammatical and syntax evaluation would be in favor of the manuscript. Overal my suggestion is Accept.

Comments on the Quality of English Language

As that comments submitted above. 

 

Author Response

Dear Editor,

We would like to thank you for the careful editorial assessment of our manuscript entitled “A Procedure for Vulnerability Analysis and Countermeasures in IoT Systems Based on their Components Characteristics”. We appreciate the opportunity to revise the manuscript and address the comments provided. Below, we describe how each point has been comprehensively addressed in the revised version of the paper.

1. Clarification and strengthening of the contribution to Machine Learning and Knowledge Extraction

We have substantially revised the manuscript to explicitly clarify and strengthen its contribution within the field of Machine Learning and Knowledge Extraction (MAKE), as suggested.

In particular, we have:

• Revised the Abstract to explicitly frame the proposed approach as a knowledge-centric methodology and to highlight the role of structured and interpretable knowledge extraction in IoT security analysis.
• Expanded and restructured the Introduction to position the work within contemporary research frontiers in MAKE. A new discussion explicitly aligns the proposed methodology with knowledge-centric and hybrid approaches, as identified in the strategic paper by Holzinger et al. (Research Frontiers in Machine Learning & Knowledge Extraction).
• Clearly articulated the methodological and conceptual novelty of the work, emphasizing how heterogeneous IoT asset information is systematically transformed into explicit, graph-based security knowledge that supports interpretability, traceability, and human-centered analysis.
• Refined the statement of contributions to highlight the advancement of domain-driven knowledge extraction for IoT security, complementing data-driven machine learning approaches rather than replacing them.
• Strengthened the Conclusions to explicitly discuss the contribution of the proposed framework from a MAKE perspective and its alignment with current research directions, including future hybrid symbolic–statistical extensions.

These revisions make explicit how the proposed approach advances existing methods and frameworks by providing a structured, interpretable, and reusable knowledge extraction pipeline for IoT vulnerability analysis, thereby improving its scientific relevance and positioning for the international MAKE research community.

2. Figure quality and presentation issues (Figures 11–18)

We have fully addressed the concerns regarding figure quality. Figures 11 to 18 have been completely regenerated as original, high-quality digital graphics, replacing the previous photographic images. The revised figures ensure:

• Improved clarity and readability;
• Consistent visual style across all figures;
• Proper resolution and formatting suitable for publication;
• Enhanced reproducibility and interpretability of the reported results.

All figures are now provided as original digital graphics, in compliance with MDPI presentation standards.

We believe that these revisions comprehensively address both the scientific positioning and the presentation issues raised in the editorial assessment. We are grateful for the constructive feedback, which has helped us significantly improve the clarity, rigor, and relevance of the manuscript.

We hope that the revised version will now be suitable for further consideration in Machine Learning and Knowledge Extraction.

Kind regards,

Ponciano Jorge Escamilla-Ambrosio
(on behalf of all authors)

Author Response File: Author Response.docx