Ontology-Driven Learning: Solving the Domain-Dependency Trap in Security Requirements

TL;DR

Manually identifying security requirements in massive software specifications is like finding a needle in a haystack. This paper presents an Ontology-based approach that moves beyond simple keyword matching. By using formal Description Logic and linguistic patterns, the authors built a classifier that "understands" the structure of a security claim, leading to a 43% improvement in F1-score when applied across different industrial domains.

The Problem: Why Keywords are Not Enough

Most existing automated requirement classifiers are "shallow." They look for keywords like "password" or "encryption" and calculate their frequency. While this works within a single project, it fails miserably when moving from, say, a banking app to a medical device system.

The core issue is Overfitting. Prior SOTA models lean too heavily on domain-specific terminology. If the training set doesn't see a specific term, the classifier misses the requirement entirely, even if the structure of the sentence clearly describes a security constraint.

Methodology: The Core Hierarchy

The authors bridge the gap between abstract security concepts and concrete natural language through a two-layer architecture.

1. The Conceptual Layer (The "Brain")

Using Description Logic (DL), the authors defined what a security requirement is. Is it protecting an Asset? Eliminating a Threat? Or providing a Countermeasure? This formalization ensures that the model isn't just looking for words, but for the relationships between entities.

2. The Linguistic Layer (The "Translator")

This layer maps ontological concepts to Linguistic Rules. For example, a "Threat-based" rule is defined as: <Subject> <Eliminate> <Threat>

3. Automated Keyword Mining

To ensure the model is domain-independent, the authors mined keywords from the IT-Grundschutz Catalogues (a 2,700-page security standard). They used a combination of TF-IDF (for single words) and Syntax-based Phrase Mining (for complex terms like "Brute Force" or "Unauthorized Access") to create a robust, generalized feature set.

Experiments: Proving Generalization

The researchers tested their approach against the famous PROMISE repository and industrial datasets (ePurse, CPN, GP).

SOTA Comparison

The most impressive result came from the Cross-Domain tests. When the model was trained on one domain and tested on another:

• Prior Work (Knauss et al.): F1-score of 0.44
• Proposed Approach: F1-score of 0.63

This demonstrates that by focusing on the syntax of a security claim rather than just the vocabulary, the model becomes much more versatile.

Deep Insights: The "Analyst" Factor

A fascinating segment of the study (Experiment 4) looked at whether the quality of the original requirement (written by Junior vs. Senior students) affected the AI. The results were clear: Classifiers performed significantly better on requirements written by seniors (Precision 0.81 vs 0.27).

This highlights a critical reality in Software Engineering AI: Garbage In, Garbage Out. If the human analyst doesn't understand security concepts well enough to write a structured requirement, even the most advanced ontology-based AI will struggle to classify it correctly.

Critical Analysis & Conclusion

While this work is a major step forward, it still relies on Tregex-based pattern matching, which can be brittle compared to modern Transformer-based models (like BERT or GPT). However, the Ontology itself provides a "Safety Rail" that neural networks often lack, ensuring the model's decisions are grounded in established security theory.

Future Outlook: The next frontier will likely involve integrating these formal Ontologies into Large Language Models (LLMs) to provide the "reasoning capability" of DL with the "linguistic flexibility" of Generative AI.