💻 computer science

A Transfer Learning Approach to Unveil the Role of Windows Common Configuration Enumerations in IEC 62443 Compliance

This paper proposes a transfer learning approach that leverages labeled Linux datasets to map Windows Common Configuration Enumerations (CCEs) to IEC 62443-3-3 requirements, thereby enabling automated compliance checks and bridging the gap between abstract security standards and concrete Windows configurations in heterogeneous industrial control systems.

Original authors: Miguel Bicudo, Estevão Rabello, Daniel Menasché, Paulo Segal, Claudio Segal, Anton Kocheturov, Priyanjan Sharma

Published 2026-02-17

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Miguel Bicudo, Estevão Rabello, Daniel Menasché, Paulo Segal, Claudio Segal, Anton Kocheturov, Priyanjan Sharma

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the head of security for a massive, high-tech factory. This factory runs on a mix of different computer systems: some are old-school, some are super-fast specialized machines, and many run on Windows (like the computers you use at home or work) and Linux (a different, very popular type of computer system used by servers).

Your job is to make sure the whole factory follows a strict rulebook called IEC 62443. This rulebook is like a giant, complex instruction manual on how to keep the factory safe from hackers. It says things like, "You must lock the front door," or "You must check the logs every night."

The Problem: The "Translation" Gap

Here is the trouble: The rulebook is written in a very abstract language. It tells you what to do, but not how to do it on a specific computer.

The Linux Situation: For Linux computers, experts have already done the hard work. They created a "Rosetta Stone" (a translation guide) that says: "If you want to follow Rule #5, here is the exact setting you need to change in Linux."
The Windows Situation: For Windows computers, this guide is missing. We know the rules, but we don't know which specific Windows settings (like registry keys or group policies) actually satisfy those rules.

Trying to figure this out for Windows from scratch is like trying to learn a new language by reading a dictionary with no examples. It takes forever and is prone to errors.

The Solution: "Transfer Learning" (The Smart Copycat)

The authors of this paper came up with a clever trick called Transfer Learning. Think of it like this:

Imagine you are a master chef who knows exactly how to cook a perfect steak on a gas grill (Linux). You have a detailed recipe book for the gas grill. Now, you need to cook the exact same steak on a charcoal grill (Windows). You've never used charcoal before, but you know the goal is the same: a juicy, safe steak.

Instead of starting from zero, you use your knowledge of the gas grill to guess how the charcoal grill works. You say, "On the gas grill, I turn the knob to 'High' to get 500 degrees. On the charcoal grill, I probably need to pile up more coals to get that same heat."

In the paper, the researchers did this with computer data:

The "Gas Grill" (Source): They took the known Linux settings and the rulebook connections.
The "Charcoal Grill" (Target): They looked at the Windows settings.
The "AI Translator": They used an AI (a type of smart computer program) to compare the descriptions of the Linux settings with the Windows settings. Even though the words are different, the AI realized that "disabling a remote login on Linux" sounds very similar to "blocking a remote port on Windows."

The Process: How They Did It

Vectorization (Turning Words into Coordinates): They turned the text descriptions of every setting into a list of numbers (like a GPS coordinate). If two settings (one Linux, one Windows) are close together on this map, they are likely doing the same thing.
The "Guessing Game": The AI looked at a Windows setting and asked, "Which Linux setting is my closest neighbor?" It then borrowed the rulebook connection from that Linux neighbor.
Tuning the Sensitivity: They had to be careful not to guess too wildly. They adjusted a "knob" (a mathematical parameter) to make sure the AI didn't just guess the most popular rules for everything, but actually found the right specific matches.
Human Check (The Taste Test): The AI made a first draft of the translation. Then, human experts (and even another AI, Gemini) tasted the food. They checked: "Does this Windows setting actually satisfy the rulebook?"
- Yes: Keep it.
- No: Throw it out.
- Maybe: Mark it for later.

What They Found

After all this work, they created a new "Rosetta Stone" for Windows. Here are the big takeaways:

Windows is all about "Policies": The rules that Windows settings satisfy are mostly about enforcing policies (making sure settings are locked down) and network boundaries (keeping bad guys out).
The Language is Different: Linux settings often talk about "packages" and "daemons" (technical terms for background programs). Windows settings talk about "enabled," "disabled," "auditing," and "policies." It's a more "command-and-control" style.
Automation is Possible: Because they now have a map, computers can automatically scan a Windows system and say, "Hey, you are 90% compliant with the security rulebook!" without a human having to read thousands of pages of manuals.

The Bottom Line

This paper is like building a bridge between a known world (Linux security) and an unknown world (Windows security). By using a smart AI to "borrow" knowledge from one side and refining it with human experts, they made it much easier to secure industrial factories running on Windows.

Instead of manually checking every single switch in a factory, we can now use software to automatically verify that the switches are in the right place, keeping our critical infrastructure safe from cyberattacks.

1. Problem Statement

Industrial Control Systems (ICS) operate in heterogeneous environments where Linux, proprietary real-time OSs, and Windows coexist. While the IEC 62443-3-3 standard provides a robust framework for securing these systems, automating compliance verification remains difficult, particularly for Windows platforms.

The Gap: Existing research and datasets have focused heavily on Linux systems (specifically SUSE Linux), where mappings between configuration settings and IEC 62443 System Security Requirements (SRs) are available.
The Challenge: Windows environments lack systematic, labeled datasets mapping their configurations to IEC 62443 SRs. Manually mapping thousands of Windows configurations is resource-intensive and prone to error.
The Goal: To automate the assessment of IEC 62443-3-3 compliance in Windows systems by leveraging existing labeled data from Linux systems.

2. Methodology

The authors propose a transfer learning pipeline that maps Windows Common Configuration Enumerations (CCEs) to IEC 62443-3-3 requirements using labeled SUSE Linux CCEs as the source domain. The process involves four main stages:

A. Data Preparation and Embedding

Source Data: SUSE Linux CCEs with known associations to IEC 62443 SRs.
Target Data: Windows CCEs (which lack SR tags).
Vectorization: Both Linux and Windows CCE descriptions are converted from tabular/JSON formats into sentence embeddings using the pre-trained all-mpnet-base-v2 model (a 768-dimensional space). This captures semantic similarity between configuration descriptions across different operating systems.

B. Distance-Based Knowledge Transfer

The core mechanism transfers SR labels from Linux to Windows based on semantic proximity:

Distance Calculation: The Euclidean or Cosine distance ( $d_{ij}$ ) is calculated between a Windows configuration $i$ and a SUSE configuration $j$ in the embedding space.
Weighting Scheme: A weight $w_{ij}$ is assigned inversely proportional to the distance ( $w_{ij} = 1/d_{ij}$ ). Closer configurations exert stronger influence.
Score Aggregation: For each Windows configuration, a score vector is computed by summing the SR vectors of nearby Linux configurations, weighted by their proximity.
Power Transformation: To enhance diversity and prevent dominant requirements from overshadowing others, the weights are raised to a power $p$ ( $w^p$ ). The authors tuned $p=5.5$ (for cosine distance) to achieve a diversity index ( $M(p)$ ) of approximately 0.85.

C. Selection and Filtering

Ranking: For each Windows CCE, the top $K$ (set to 10) requirements with the highest scores are selected.
Thresholding: A threshold $\tau$ (set to 0.68) is applied to ensure only high-confidence associations are retained.
Normalization: Scores are normalized to the $[0, 1]$ interval using the $\ell_\infty$ norm to ensure comparability.

D. Validation

Manual Verification: Two human experts manually verified the top-10 mappings for 612 Windows CCEs, resulting in 3,020 relations.
LLM Cross-Check: The human labels were compared against Gemini 2.5 Flash. The LLM showed 95.6% agreement with human assessors, validating the consistency of the labeling process.

3. Key Contributions

Transfer Learning Framework: A novel methodology to bridge the data gap between Linux and Windows by transferring security requirement knowledge via semantic embeddings.
Labeled Dataset: The creation of a curated dataset mapping 612 Windows CCEs to IEC 62443-3-3 System Security Requirements, with 937 accepted "Yes" associations.
Empirical Analysis: A detailed analysis of requirement prevalence and co-occurrence patterns in Windows, revealing how security controls cluster (e.g., access control vs. patch management).
Cross-Platform Insights: Identification of semantic and structural differences between Linux and Windows compliance landscapes, highlighting the need for platform-specific validation.

4. Key Results and Findings

Dataset Statistics:
- Initial ML output: 3,060 relations.
- After manual filtering: 3,020 relations.
- Acceptance Rate: 31% (937 "Yes"), 7% "Maybe", 61% "No".
- LLM Agreement: 95.6% overall agreement with human labeling.
Dominant Security Themes:
- The most frequently accepted mappings were SR 7.6 (Security parameter enforcement) and SR 5.2 (Network boundary protection).
- Other high-frequency areas included SR 6.2 (Continuous monitoring) and SR 6.1 (Audit log generation).
- Insight: Windows compliance is heavily driven by operational controls (perimeter defense, policy enforcement) rather than physical or organizational controls.
Semantic Differences:
- Linux CCEs tend to use procedural language (e.g., "package," "service," "daemon").
- Windows CCEs use prescriptive, directive language (e.g., "enabled," "disabled," "policy," "enforced").
- This linguistic divergence confirms that while embedding similarity is useful, semantic adaptation and manual validation are critical for accurate cross-platform mapping.
Clustering: Unsupervised clustering of SRs revealed that security controls are not applied independently but in functional groups (e.g., authentication clusters, integrity/patching clusters).

5. Significance and Impact

Automation of Compliance: The approach enables automated compliance checks for Windows-based ICS components (HMIs, SCADA), which were previously difficult to assess systematically.
Traceability: It establishes a clear, traceable link between abstract IEC 62443 requirements and concrete Windows configuration settings (Registry keys, Group Policies).
Standardization: The work advances the integration of IEC 62443 with other frameworks (e.g., NIST 800-82, ISO/IEC 27001) by providing a structured, machine-readable dataset.
Practical Utility: The resulting dataset allows practitioners to identify gaps in Windows hardening and prioritize configurations that address the most critical security requirements.

In conclusion, this paper successfully demonstrates that transfer learning can effectively overcome data scarcity in industrial cybersecurity, providing a scalable path to automate IEC 62443 compliance for heterogeneous Windows environments.