HAL 9000: Risk Manager for ITS

• HAL 9000 is a risk manager for ITSs that uses machine learning to predict CVSS scores and dynamically assess security risks.
• It integrates automated clustering of vulnerability descriptions with real-time OSINT from sources like NVD, ExploitDB, OTX, and OSV.
• The system enhances resilience by prioritizing configurations that minimize shared vulnerabilities through EPSS and OTX pulse integrations.

HAL 9000 is a risk manager for Intrusion Tolerant Systems (ITSs) that provides automated security configuration recommendations by integrating machine learning-based vulnerability assessment, clustering, and dynamic risk scoring using diverse OSINT sources. It addresses the challenge of delayed and incomplete CVE scoring in conventional databases such as the National Vulnerability Database (NVD) and ExploitDB by employing predictive models and an extensible intelligence acquisition infrastructure. The system includes a custom scraper to collect data from multiple threat intelligence sources, enabling near-real-time adaptation to emerging threats and improving the fidelity of both security and resilience risk assessments (Freitas et al., 18 Aug 2025).

1. System Objectives and Core Architecture

HAL 9000 is designed to optimize the deployment of ITSs by recommending software/OS configurations that minimize aggregate security risks while maximizing architectural resilience against exploits that can compromise diverse system replicas. The motivation is to overcome the constraints of earlier ITS risk managers:

• Heo et al.: Focuses on minimizing summed CVSS risk but depends strictly on NVD data.
• Lazarus: Adds clustering for similar CVEs and risk reassessment with factors like vulnerability age and patch status, but still relies on manual CVE score assignment and cluster tuning.

HAL 9000 surpasses these baselines by incorporating:

• Predictive ML models for estimating CVSS scores of new/unscored CVEs.
• Automated description-based clustering to identify similar or related vulnerabilities across software/OS platforms.
• Advanced risk reassessment accounting for exploitability, real-time intelligence, and patch dynamics.
• A configuration engine that prioritizes resilience (shared vulnerability minimization) alongside aggregate risk.

Core Architectural Components:

1. Vulnerability Score Predictor: ML-based CVSS inference for unscored CVEs.
2. Clustering Algorithm: Automatic grouping of vulnerabilities with textual and latent similarities.
3. Score Reassessment Module: Risk recalibration using exploit intelligence, age decay, patch status, EPSS, and OTX indicators.
4. Configurator: Evaluation and ranking of all feasible ITS configurations based on quantitative security and resilience metrics.

Workflow:

• Ingests vulnerability feeds.
• For CVEs missing scores, applies the ML predictor.
• Clusters all CVEs to expose shared-weakness pathways.
• Computes risk for each configuration.
• Outputs best configuration(s) per resilience-first, security-sensitive criteria.

2. Risk Scoring and Exploitability Quantification

Risk scoring in HAL 9000 extends the Lazarus model, introducing layers of exploitability analytics:

2.1. Baseline (Lazarus) Reassessment

The foundational formula is:

$$score(v) = CVSS(v) \times oldness(v) \times exploited(v) \times patched(v)$$

Where:

• $$oldness(v) = \max(1 - 0.25 \frac{\text{now} - v.\text{published\_date}}{\text{threshold}}, 0.75)$$
• $patched(v) = 0.5^{v.\text{patched}}$
• $exploited(v) = 1.25^{v.\text{exploited}}$

This framework discounts older, patched vulnerabilities but increases risk for those with active exploitation.

2.2. EPSS Extension

By integrating the Exploit Prediction Scoring System (EPSS)—specifically, the 30-day probability of exploitation—HAL models expected risk as:

$$hal\_score(v) = score(v) \cdot (1 - EPSS(v)) + score(v)_{wp} \cdot EPSS(v)$$

with $score(v)_{wp}$ denoting the worst-case (unpatched) risk.

2.3. OTX Pulse Signal Integration

Adding AlienVault OTX pulse counts further refines prioritization of threats seen in active campaigns:

$$hal\_score(v) = \min\Big(10, score(v) \cdot (1 - EPSS(v)) + score(v)_{wp} \cdot EPSS(v) + \log(\#\text{related\_pulses})\Big)$$

Capping at 10 conforms to CVSS semantics.

2.4. Configuration Risk Metrics

Security risk is quantified as:

$$security\_risk(config) = \sum_{n_i \in config} \sum_{v \in V(n_i)} hal\_score(v)$$

Resilience risk is:

$$resilience\_risk(config) = \sum_{n_i, n_j \in config} \sum_{v \in V(n_i, n_j)} hal\_score(v)$$

Where $V(n_i)$ denotes vulnerabilities for software/OS $$oldness(v) = \max(1 - 0.25 \frac{\text{now} - v.\text{published\_date}}{\text{threshold}}, 0.75)$$0, and $$oldness(v) = \max(1 - 0.25 \frac{\text{now} - v.\text{published\_date}}{\text{threshold}}, 0.75)$$1 those shared (including by cluster similarity) for node pairs.

Empirical Example (CVE-2017-11882):

Model	Score
NVD CVSS	7.8
Lazarus	3.65
HAL + EPSS	7.2
HAL + EPSS + OTX pulses	8.9

This result demonstrates the improved realism of HAL's risk prioritization for in-the-wild exploitation (Freitas et al., 18 Aug 2025).

3. Machine Learning for Vulnerability Assessment and Clustering

HAL 9000 employs ML to enable timely vulnerability risk calibration:

3.1. CVSS Prediction for New CVEs

• Goal: Generate CVSS estimates for recently disclosed or low-visibility CVEs lacking NVD assessment.
• Input: CVE descriptions (and, where present, associated metrics).
• Process: Supervised ML trained on historical CVEs with verified scores.

Implemented Models:

Model	Accuracy	RMSE	Time (s)	Classifier
Khazaei et al.	99%	0.66	132.85	Random Forest
Costa et al.	87%	1.55	1432.14	Linear
VulDistilBERT	90%	3.63	195.49	Linear

HAL deploys Khazaei et al.'s Random Forest for optimal precision and runtime in operational settings.

3.2. Automated Clustering of Vulnerability Descriptions

• Purpose: Detect latent equivalence or similarity between CVEs that would otherwise evade standard deduplication.
• Preprocessing: Sentence embeddings (outperforms BoW).
• Clustering Algorithm: OPTICS (preferred) or DBSCAN (alternate).
• Rationale: Both algorithms avoid the need for manual cluster number selection (as in K-means), are robust to outliers, and scale to rapid OSINT-driven data growth.

This component is critical to correctly modeling shared-weakness risks in ITS replication scenarios (Freitas et al., 18 Aug 2025).

4. Threat Intelligence Acquisition via Custom-Built Scraper

To overcome the limitations of database lag or incomplete coverage, a custom scraper continuously ingests data from:

• NVD: Via API (rate-limited, JSON fields).
• ExploitDB: Not directly scrapeable; uses the Searchsploit CLI tool for reliable, automated exploit extraction.
• AlienVault OTX: API-based retrieval of pulse/indicator data with rate enforcement, necessitating delays for large-scale collection.
• OSV: Initial bulk import via Google Cloud Storage, followed by periodic API refresh.

Operational Parameters:

• Scrape frequency: hourly.
• Data pipeline: JSON preprocessing, cleansing, PostgreSQL key-value storage.
• Scraper implementation: Rust (1,268 LOC), available in the vex_hk repository.
• Resulting data volume: ~2 GB covering hundreds of thousands of entries per source.

OSINT DB	Scrapable	Execution Time (s)	API Key	#Entries	Request Limits
NVD	Yes	390.29	Yes	277,152	50/30s (with key)
ExploitDB(*)	Yes*	3.42	No	46,575	N/A
AlienVault OTX	Yes	99,774	Yes	277,152	10,000/3600s
OSV(*)	Yes*	235.44	No	255,743	None

(*) Data acquired via bulk file download for initial load.

The scraper's output feeds exclusively into HAL’s local intelligence DB, decoupling configuration assessment from live fetch latency.

5. Extended Architecture and System Integration

The extended HAL architecture encompasses three main layers:

1. External Data Acquisition Layer: Automated periodic scraping of all selected OSINT sources.
2. Local Intelligence Layer: Preprocessed threat data in a structured PostgreSQL store, queried by HAL’s analytic modules.
3. HAL 9000 Processing Layer: Ingests intelligence, applies ML prediction/clustering, performs risk (re)scoring, and emits configuration recommendations.

Data Flow:

$$oldness(v) = \max(1 - 0.25 \frac{\text{now} - v.\text{published\_date}}{\text{threshold}}, 0.75)$$2

The external scraper, local database, and decision engine operate asynchronously, decoupling decision latency from OSINT fetch intervals.

6. Quantitative Evaluation and Comparative Performance

Significant empirical results include:

• Clustering Performance: Sentence embeddings + OPTICS minimizes risk estimation error versus BoW + K-means, eliminating need for manual parameter tuning and improving outlier robustness.
• Configuration Risk: HAL achieves both better resilience (minimizing shared vulnerabilities) and superior cumulative security risk mitigation compared to Heo and Lazarus, with several months in 2023 showing dominant metrics in both dimensions.
• Realism in Risk Reassessment: The CVE-2017-11882 case illustrates that legacy patch-weighted scoring (e.g., Lazarus) can understate risk in the presence of active exploitation; HAL’s EPSS and OTX signal adjustment re-aligns risk magnitude with contemporary threat landscape.
• OSINT Expansion: The scraper increases both coverage and timeliness—spanning over 275,000 entries per major source—enabling earlier detection and scoring of otherwise overlooked vulnerabilities.
• ML Predictor Accuracy: The adopted Random Forest predictor achieves 99% accuracy and RMSE of 0.66, outpacing deep learning and transformer-based alternatives for real-time operational use.

7. Limitations and Future Work

Limitations

• Adversarial Manipulation Risk: HAL must be secured against OSINT DB tampering, ML poisoning, and manipulation of input intelligence.
• Source Trustworthiness: As HAL expands beyond curated databases, it becomes vulnerable to misinformation including fake CVEs, bot-driven amplification, and open-source/social network contamination.
• Source-Specific Operational Barriers: AlienVault OTX is particularly constrained by rate limiting and lack of batch extraction; ExploitDB requires continual synchronization with external tool updates.
• Provisional Nature of ML Scoring: Predicted CVSS values are intended as interim placeholders pending authoritative human analysis.

Future Directions

The proposed roadmap includes:

• Augmenting Source Coverage: Integration of penetration testing outputs, automated testing, alternative intelligence feeds, and dark web data streams.
• Misinformation Filtering: Enhanced provenance tracking, cross-referencing, ML-based anomaly filters, and source weighting.
• Deployment in Live ITSs: Evaluation of end-to-end risk management in production settings with analysis of system overhead.
• Scraper Enhancements: Expansion of source breadth and strengthening of data vetting procedures prior to DB insertion (Freitas et al., 18 Aug 2025).