{"id":"7483078a-4862-44c9-9ba9-0f9c4ee9e7bf","arxiv_id":"2507.10819","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":1.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A Spanish-language technical report that compiles existing knowledge on IIoT vulnerabilities, attacks, and machine-learning-based countermeasures without adding new research findings.","lead":"This technical report surveys security vulnerabilities in Industrial Internet of Things (IIoT) systems by cataloging attack vectors, targets, impacts, consequences, and selected real-world incidents, then reviews countermeasures with emphasis on machine learning. It is a useful orientation document for security engineers and managers new to IIoT, but it presents no new experimental, theoretical, or measurement results.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Table 2's promise of 'real documented attacks' is the central pillar, and several rows cite ML/dataset papers rather than incident reports; this mismatch is the load-bearing weakness.","rationale":"The reader's weakest assumption centered on Table 2's citation support, and my independent check converges on the same point: the report's central claim to provide a reliable, organized compilation of real IIoT attacks depends on the accuracy of Table 2. The specific mismatches named by the reader are real and load-bearing, because dataset and ML-method papers do not document incidents. A survey can survive imperfect narrative framing, but it cannot survive a central evidence table whose entries are not supported by the cited sources. The countermeasure sections are less compromised because they report methods and proposals rather than historical events. The taxonomy itself is externally sourced and applied consistently, so the main issue is factual support, not internal inconsistency. I do not see a reason to move the verdict beyond conditional: the concern is specific, fixable by replacing or reclassifying unsupported rows, and the narrative portions retain value. Thus the reader's CONDITIONAL verdict should stand unchanged.","tokens_in":23210,"tokens_out":2059,"duration_ms":26690,"concrete_test":"Perform a full-text audit of every Table 2 citation, starting with entries 19, 21, and 23. For each of the 26 rows, open the cited source and search for the named attack and the specific target (e.g., 'side-channel' or 'power analysis' for row 19; 'DNS spoofing' for row 21; 'false data injection' or 'FDI' for row 23). Record whether the source describes the attack as a real incident, a hypothetical scenario, or only as a generic attack type used in a dataset/ML evaluation. Then recompute the fraction of rows with genuine incident support. If more than, say, 10% of rows lack direct support, Section 4.2 should be revised to label those entries as illustrative rather than documented, and the verdict should remain conditional until the revision is made.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 4.2 states that Table 2 collects 'ataques reales que han afectado a infraestructura IIoT' and classifies them under the Section 3 taxonomy. That claim is what makes the survey a usable reference, and it is least secure exactly where the cited evidence is weakest. Rows 19, 21, and 23 illustrate the pattern: entry 19 (side-channel attack) cites [15], the Edge-IIoTset dataset paper, which is a dataset description rather than a report of a real side-channel incident; entry 21 (DNS spoofing) cites [14], a hybrid CNN-LSTM intrusion-detection paper; entry 23 (false data injection) cites [19], an arXiv preprint on federated learning for computer vision. None of these references plausibly documents a real-world IIoT attack of the kind the table claims. If these and similar entries are not actual documented incidents, then the table is not a 'selección de casos reales' but a taxonomy exercise applied to hypothetical or misattributed cases. That weakens the report's factual core rather than merely its formatting, because the central contribution is precisely the organized, evidence-based incident list. The countermeasure survey in Section 5 is less affected, since it is framed as a bibliography of recent approaches rather than verified events.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This Spanish-language technical report surveys the Industrial Internet of Things (IIoT) security landscape. It describes IIoT devices, architectures, protocols, and controllers; imports an attack taxonomy from Panchal et al. [34] organized by vector, target, impact, and consequence; presents a nine-phase attack model; compiles a table of 26 purported real-world attacks against IIoT infrastructure classified under that taxonomy; and reviews recent security countermeasures, with special attention to machine-learning-based intrusion detection. The central stated objective is to provide an organized, evidence-based reference for IIoT threats and mitigations.","tokens_in":23434,"tokens_out":2502,"duration_ms":30349,"significance":"If the compilation is reliable, the report would be a useful structured reference for practitioners entering IIoT security: it organizes a broad and often scattered literature, provides a protocol-level vulnerability summary, and collects known industrial cyber incidents such as Stuxnet and the Ukraine power-grid attack. The report's strength is its clear scaffolding: the taxonomy-based classification of attacks and the protocol vulnerability table (Table 1) are well aligned with the cited literature, and the countermeasure survey names concrete proposals with their limitations. However, the paper's main added value—Table 2 as a selection of 'real documented attacks'—is also its weakest load-bearing element, because several entries cite machine-learning and dataset papers rather than incident reports or vulnerability disclosures. The report is therefore best assessed as a useful draft whose factual core requires substantial verification and revision before it can serve as a dependable reference.","major_comments":[{"comment":"The heading and introductory sentence of §4.2 promise 'ataques reales que han afectado a infraestructura IIoT', but rows 19, 21, and 23 cite references that do not plausibly document real-world incidents. Row 19 (side-channel attack) cites [15], the Edge-IIoTset dataset paper; row 21 (DNS spoofing in OT networks) cites [14], a hybrid CNN-LSTM intrusion-detection paper; and row 23 (false data injection in pipelines) cites [19], an arXiv preprint on federated learning for computer vision. None of these sources reports a documented attack of the type described. These citations must be replaced with actual incident reports, vulnerability advisories, or case studies; otherwise the affected rows should be explicitly relabeled as hypothetical or illustrative attacks rather than real documented incidents.","section":"§4.2, Table 2 (rows 19, 21, 23)"},{"comment":"Rows 7 (jamming of signals), 8 (infected USB device), and 9 (tailgating as social engineering) contain no citation at all. Since Table 2 is introduced as a compilation of real documented attacks, every row needs a verifiable source. If these entries are meant as generic examples of the taxonomy's physical vectors rather than documented incidents, the table's header and the accompanying text should say so explicitly, and the rows should be moved to an 'illustrative examples' section or annotated accordingly.","section":"§4.2, Table 2 (rows 7, 8, 9)"},{"comment":"Additional citation mismatches undermine confidence in the table beyond the three clearest examples. Row 16 ('Falsificación de Certificados') cites [22], a vendor blog about establishing trust in IoT/OT environments, which is not an incident report. Row 22 ('Cryptojacking en Dispositivos Edge') cites [37], a CNN-GRU intrusion-detection paper on the Edge-IIoTset dataset, which does not document a cryptojacking incident. Row 26 ('Ataque a Sistemas de Edge Computing') cites [16], which is the same Edge-IIoTset dataset paper as [15], and does not describe the race-condition attack listed. The authors should systematically audit every row of Table 2 against its cited source, replace mismatched references, and remove duplicate or irrelevant citations.","section":"§4.2, Table 2 (rows 16, 22, 26)"},{"comment":"The table mixes well-documented real incidents (e.g., Stuxnet, row 1) with generic attack scenarios that may not correspond to any public incident (e.g., battery drain, row 24; edge-computing race condition, row 26). The sentence after the table claims that 'cada uno de estos ataques ilustra' the taxonomy, but the preceding promise is stronger: 'ataques reales que han afectado a infraestructura IIoT'. The manuscript should state the inclusion criteria for Table 2, distinguish between documented incidents and illustrative taxonomy exercises, and make the evidence level of each row transparent. Without this clarification, the table's reliability as a reference work remains questionable even after individual citation fixes.","section":"§4.2, Table 2 (general)"}],"minor_comments":[{"comment":"The heading contains a typo: 'anteriror' should be 'anterior'.","section":"§4.2 (heading)"},{"comment":"Reference [31] is incomplete: it lists a journal name as 'Review (2025)' and a URL that appears truncated; it needs the full venue, volume, article number, and a working DOI.","section":"References, item [31]"},{"comment":"References [15] and [16] are the same paper (Edge-IIoTset) with identical bibliographic data; the duplicate should be removed and the in-text citations reassigned.","section":"References, items [15] and [16]"},{"comment":"In the paragraph on machine learning, 'Otro estudio en [28]' follows a sentence that already cites [28]; the reference cannot distinguish between the particle-swarm framework and the autoencoder/PCA study. The authors should split these into separate citations or clarify which work is meant.","section":"§5.2"},{"comment":"Several protocol names contain stray artifacts such as 'IIoT!s', 'PLC!s', and 'TCP!/IP!'; these should be cleaned to standard notation.","section":"§2.3"},{"comment":"Figure 8 is labeled 'Tabla de comparación de datasets de intrusiones en IIoT' but appears as a figure; if it is a reproduction of a table from [34], it should be formatted as a table or the caption should match its presentation.","section":"Figure 8"}],"recommendation":"major_revision","confidential_remarks":"The paper reads as a technical report or survey draft rather than an archival research contribution; its value is primarily as an organized reference. The central factual claim—the table of real documented attacks—is not yet supported by the cited evidence in several rows. This is fixable within the manuscript's scope by replacing mismatched references, adding sources for uncited rows, and clearly separating documented incidents from illustrative taxonomy examples. If the authors cannot supply real incident sources for the problematic rows, they should either remove those rows or explicitly recast the table as a taxonomy exercise. I would not reject outright because the structural framework is sound and the countermeasure survey is useful, but the revision must substantively address the evidence base, not merely formatting."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a competent, clearly written survey of IIoT security in Spanish, but the centerpiece attack table (Table 2) is not reliable as a collection of real documented attacks. Several rows cite machine-learning dataset papers instead of incident reports, and three rows have no citation at all.\n\nWhat it does well: the report gives a solid orientation for someone new to the area. It organizes device classes, the IIRA architecture, communication protocols, and attack phases cleanly, and it imports a workable taxonomy from Panchal et al. The countermeasure section is a reasonable literature review, with recent ML-based IDS work. The protocol vulnerability summary in Table 1 is broadly consistent with the cited sources.\n\nSoft spots: Table 2 is the load-bearing weakness. The paper explicitly calls these 'ataques reales que han afectado a infraestructura IIoT,' but entries 19, 21, and 23 cite, respectively, the Edge-IIoTset dataset paper, a CNN-LSTM intrusion-detection paper, and a federated-learning-for-computer-vision preprint. None of these plausibly documents a real-world IIoT incident. Rows 7, 8, and 9 (jamming, infected USB, tailgating) have no source at all. Also, references [15] and [16] are the same paper, which is sloppy. Because the table is the report's factual core, this is not a formatting issue: it undermines the central claim. The narrative sections and the countermeasure survey are less affected, since they are framed as reviews rather than verified events.\n\nTo be fair, the rest of the report holds up as a survey. There is no circularity problem: the taxonomy is external, and the report makes no derived claims. It just does not deliver new findings, which is consistent with its stated goal.\n\nWho it is for: practitioners, students, or project stakeholders wanting a quick map of IIoT threats and defenses. It is not a research contribution.\n\nRecommendation: I would send it to peer review, but with a clear request to fix Table 2. Either replace the citations with genuine incident sources, or reframe the table as a taxonomy exercise with illustrative or hypothetical examples. If the authors do that, it becomes a useful reference. If not, it is a well-organized but unreliable compilation.","headline":"A readable Spanish-language IIoT security survey whose central table of 'real attacks' has enough citation mismatches that it cannot be trusted as an evidence-based reference until fixed.","tokens_in":23955,"tokens_out":2113,"would_cite":false,"duration_ms":27721,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The report claims that every IIoT attack can be filed under vector, target, impact, and consequence, and that machine-learning intrusion detection is the current best defense.","keywords":["IIoT","industrial cybersecurity","vulnerability taxonomy","attack vectors","SCADA security","intrusion detection","machine learning","critical infrastructure"],"falsifier":"Check whether each cited reference in Table 2 actually documents the named incident; the side-channel, DNS-spoofing, and false-data-injection rows cite sources that appear to describe datasets or unrelated models, so if those references do not contain the incident, the compilation is unsupported. Alternatively, find one documented IIoT attack whose vector, target, impact, and consequence cannot be placed in any taxonomy category.","tokens_in":23024,"feed_emoji":"🛡️","tokens_out":7865,"duration_ms":77990,"temperature":0.7,"pith_summary":"The report tries to establish that the security of Industrial Internet of Things (IIoT) environments can be systematically understood if threats are classified along four axes: attack vector, target, impact, and consequence, following the taxonomy introduced in [34]. It assembles this classification from a survey of device classes, protocols, attack phases, and 26 documented incidents, and it argues that current countermeasures converge on machine-learning-based intrusion detection, with additional layers such as protocol-aware deep packet inspection and blockchain-edge integrity schemes. The value of the claim, if correct, is that defenders of critical infrastructure can map any IIoT incident to a standard cell in the taxonomy and then select countermeasures according to the physical or cyber consequence at stake.","feed_headline":"26 real IIoT attacks classified by one four-axis taxonomy","feed_subtitle":"A report maps IIoT threats by vector, target, impact, and consequence, then surveys machine-learning defenses","key_machinery":"The load-bearing mechanism is the four-axis classification of IIoT attacks: vector (cyber or physical), target (cyber or physical), impact (cyber or physical), and consequence (cyber or physical), inherited from the survey [34] and rendered as Table 2's 26 incident rows. Because each incident is forced into one cell per axis, the taxonomy turns qualitative case reports into a comparable grid; the grid is what supports the report's later inference that defenses must address both digital compromise and physical harm.","core_discovery":"On its own terms, the report's central discovery is that the IIoT attack space is not a scattered list of incidents but a structure: every attack can be located by its vector (cyber or physical), its target (cyber or physical), its impact on the compromised system, and its final consequence for the industrial process. The report adopts the taxonomy proposed in [34], applies it to a table of 26 real-world attacks, and then surveys countermeasures, concluding that availability and integrity are the most critical security requirements in IIoT and that machine learning is the key technology for meeting them.","pith_inferences":["If the taxonomy is complete, it could be turned into a lookup schema for mapping newly reported IIoT incidents to known countermeasure families; I would test this by coding vectors, targets, impacts, and consequences for incidents from vulnerability databases and checking whether any case falls outside the grid.","The report's own examples suggest a testable extension: entries whose citations describe datasets or unrelated models rather than the named incident (e.g., side-channel, DNS spoofing, false data injection) could be re-verified; if they cannot be supported, the empirical table needs revision but the taxonomy itself may still stand.","Because availability and integrity are stated as top priorities, one concrete extension is to rank countermeasures by the severity of physical consequence they prevent, not by detection accuracy alone."],"forward_implications":["If the taxonomy is accepted, IIoT incident reports can be standardized by filling in vector, target, impact, and consequence, making disparate attacks comparable.","The protocol vulnerability table implies that widely used industrial protocols lack authentication or encryption by default, so network-level defenses must assume plaintext and unauthenticated traffic.","The report's survey suggests that signature-based intrusion detection alone is insufficient and that hybrid machine-learning-based detection is the current effective direction for IIoT.","The 26-case compilation supports the conclusion that consequences can be physical, such as defective products, machine breakage, or environmental disaster, so security investment should be tied to physical risk rather than only data risk."],"supporting_citations":[{"why":"Supplies the vector-target-impact-consequence taxonomy that the report uses to classify every vulnerability and incident.","marker":"[34]"},{"why":"Documents the Stuxnet attack, used as the first row in the incident table to show physical consequences.","marker":"[11]"},{"why":"Provides the protocol threat summary and communication-protocol basis for the table of protocol vulnerabilities.","marker":"[31]"},{"why":"Supplies the IIoT environment model and motivates the need to adapt IT attack lifecycles to IIoT.","marker":"[18]"},{"why":"Supports rows on firmware tampering and legacy-protocol exploits and contributes the DDoS threat framing.","marker":"[5]"},{"why":"Introduces the deep-learning intrusion detection model cited as evidence that ML defenses are state of the art.","marker":"[1]"},{"why":"Describes the hybrid machine-learning IDS at the edge, a core example in the countermeasures section.","marker":"[46]"},{"why":"Describes machine-learning vulnerability analysis for SCADA networks used in the SCADA protection section.","marker":"[49]"},{"why":"Presents deep packet inspection for Modbus/TCP, used as a protocol-specific countermeasure.","marker":"[33]"}],"fun_headline_variants":["IIoT attack taxonomy classifies 26 real cases","26 industrial IoT attacks sorted by four axes","New report maps IIoT threats by vector and impact","Machine learning top defense in IIoT attack report"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The report rests on the assumption that the taxonomy of [34] is a valid and complete way to classify IIoT attacks, and that the 26 incidents in Table 2 are each accurately supported by the reference cited beside them.","fun_headline_variants_meta":{"raw":{"variants":["IIoT attack taxonomy classifies 26 real cases","26 industrial IoT attacks sorted by four axes","New report maps IIoT threats by vector and impact","Machine learning top defense in IIoT attack report"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000159,"raw_usage":{"total_tokens":1202,"prompt_tokens":890,"completion_tokens":312,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":506,"completion_tokens_details":{"reasoning_tokens":252}},"tokens_in":506,"tokens_out":312,"duration_ms":4333,"temperature":1.0,"reasoning_tokens":252,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T17:23:41.090723+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Check whether each cited reference in Table 2 actually documents the named incident; the side-channel, DNS-spoofing, and false-data-injection rows cite sources that appear to describe datasets or unrelated models, so if those references do not contain the incident, the compilation is unsupported. Alternatively, find one documented IIoT attack whose vector, target, impact, and consequence cannot be placed in any taxonomy category.","supporting_citations":[{"cited_title":"Security Issues in IIoT: A Comprehensive Survey of Attacks on IIoT and Its Countermeasures","cited_arxiv_id":null,"evidence_quote":"Supplies the vector-target-impact-consequence taxonomy that the report uses to classify every vulnerability and incident."},{"cited_title":"Stuxnet: What Has Changed?","cited_arxiv_id":null,"evidence_quote":"Documents the Stuxnet attack, used as the first row in the incident table to show physical consequences."},{"cited_title":"Cybersecurity for Industrial IoT (IIoT): Threats, countermeasures, challenges and fu- ture directions","cited_arxiv_id":null,"evidence_quote":"Provides the protocol threat summary and communication-protocol basis for the table of protocol vulnerabilities."},{"cited_title":"X-IIoTID: A Connectivity- and Device-agnostic Intrusion Dataset for Industrial Internet of Things","cited_arxiv_id":null,"evidence_quote":"Supplies the IIoT environment model and motivates the need to adapt IT attack lifecycles to IIoT."},{"cited_title":"DDoS attacks in Industrial IoT: A survey","cited_arxiv_id":null,"evidence_quote":"Supports rows on firmware tampering and legacy-protocol exploits and contributes the DDoS threat framing."},{"cited_title":"DeepIFS: Intrusion detection approach for industrial internet of things traffic in fog environ- ment","cited_arxiv_id":null,"evidence_quote":"Introduces the deep-learning intrusion detection model cited as evidence that ML defenses are state of the art."},{"cited_title":"Hybrid intrusion detection system for edge-based IIoT relying on machine-learning-aided detection","cited_arxiv_id":null,"evidence_quote":"Describes the hybrid machine-learning IDS at the edge, a core example in the countermeasures section."},{"cited_title":"Machine learning-based network vulnerability analysis of industrial internet of things","cited_arxiv_id":null,"evidence_quote":"Describes machine-learning vulnerability analysis for SCADA networks used in the SCADA protection section."},{"cited_title":"Deep packet inspection in industrial automation control system to mitigate attacks exploiting modbus/TCP vulnerabilities","cited_arxiv_id":null,"evidence_quote":"Presents deep packet inspection for Modbus/TCP, used as a protocol-specific countermeasure."}],"review_version":1}