Bridging the Semantic Gap: Identifying Security Requirements through Linguistic Intelligence

TL;DR

Security is often the "forgotten requirement," buried deep within pages of technical specifications. This paper introduces a tool-supported method that moves beyond simple keyword matching. By distilling security expertise into 47 specific linguistic rules and combining them with Machine Learning (J48 Decision Trees), the author provides a way to identify security requirements that actually works across different application domains—from electronic purses to network systems.

The Problem: When "Security" Doesn't Say "Security"

Most automated tools for Identifying Security Requirements (SR) rely on lexical statistics—counting how many times words like "password" or "encryption" appear. However, this creates a major "Overfitting" trap:

1. Domain Dependency: A classifier trained on banking software fails on medical devices because the vocabulary changes, even if the underlying security logic (e.g., access control) is identical.
2. Implicit Requirements: Many critical security constraints don't use "obvious" keywords, leading to high false-negative rates.

The core motivation of this work is to inject semantic comprehension into the classification process.

Methodology: Teaching Machines the "Grammar of Security"

The author transforms the problem from "statistical classification" to "linguistic pattern matching" through a three-layer approach:

1. The Ontology-Based Conceptual Model

Instead of a flat list of words, the method uses a revised version of Firesmith's conceptual model. It defines the relationships between Assets, Threats, Security Properties, and Countermeasures (Mechanism vs. Constraint).

2. Linguistic and Compound Rules

The author derived 47 rules (8 atomic, 39 compound). For example:

• Atomic Rule (T): <Subject> <Eliminate> <Threat>
• Compound Rule (CATS): <Subject> <Provide> <SecurityMechanism> to <Protect> <Asset> from <Threat> to <Achieve> <SecurityProperty>

3. Syntactic Matching via Parse Trees

Instead of looking for these rules as literal strings, the tool uses the Stanford Parser to generate Parse Trees. It employs TGrep2 syntax to find isomorphic structures in natural language, allowing it to recognize a requirement even if it has complex adjectives or weird phrasing.

Experiments: The Generalization Test

The study compared the proposed method against a probability-based benchmark using three distinct industrial specifications: ePurse, CPN, and GP.

Key Findings:

• The Classifier Winner: While several algorithms were tested (Naive Bayes, SMO, PART), the J48 Decision Tree proved most robust to the "noise" inherent in human-written requirements.
• Cross-Domain Mastery: The most significant result appears in Experiment 3. When a classifier trained on ePurse was asked to identify requirements in CPN, the linguistic approach achieved much higher F-Measures (e.g., 0.63 vs 0.33) than the benchmark.

Critical Insight: Why Syntax Trumps Statistics

The reason statistical models (the benchmark) fail across domains is that they learn vocabulary. If a new domain calls a "user" a "client," the statistical model breaks.

By contrast, the linguistic rule approach learns the structure of a security claim. Whether you are protecting "financial data" or "patient records," the sentence structure "System shall [Protect] [Asset] from [Threat]" remains constant. This Inductive Bias toward linguistic structure is what enables the 18% jump in precision observed in cross-domain tests.

Conclusion and Future Outlook

This paper proves that "Domain-General" SR classification is possible by encoding domain expertise into linguistic patterns.

Future directions suggested by the author include:

• Dependency Analysis: Moving beyond simple parse trees to capture deeper semantic relationships.
• Fuzzy Matching: Using word embeddings (word2vec) to handle synonyms more gracefully than strict keyword stemming.
• Industry Integration: Moving from a prototype to a production-ready CASE tool.

For the modern security engineer, this work offers a blueprint for how NLP can move from mere "text mining" to true "requirements understanding."