Evaluation preview: Preliminary research material. MITRE ATT&CK associations are subject to technical review. This page does not represent peer review, independent validation, or formal final publication.

IAIGCRM Threat Hunting & Detection Engineering Taxonomy

Version: 0.1 — Editorial Review Draft

Institution: Institute for AI Governance, Cybersecurity & Risk Management (IAIGCRM)

Research Domain: Cybersecurity | Threat Hunting | Detection Engineering

Status: Approved for Retention — Not Authorized for Publication

Date: October 22, 2026

1. Executive Overview

The IAIGCRM Threat Hunting & Detection Engineering Taxonomy establishes a structured framework for identifying, investigating, simulating, and reporting potentially malicious activity across enterprise information systems.

The framework organizes threat-hunting activities into 20 analytical categories and aligns them with relevant techniques and tactics from the MITRE ATT&CK knowledge base.

Its objectives are to:

Establish a consistent taxonomy for cybersecurity threat hunting.
Support the development of reusable Splunk Search Processing Language (SPL) detections.
Associate detection hypotheses with MITRE ATT&CK techniques.
Enable controlled laboratory simulation and verification.
Evaluate security monitoring effectiveness and telemetry coverage.
Provide repeatable investigation and reporting methodologies.

The taxonomy is intended for security operations centers, threat hunters, detection engineers, cybersecurity researchers, auditors, and security control assurance professionals.

Research qualification: This taxonomy is an IAIGCRM research framework. Its ATT&CK mappings are preliminary associations and should not be interpreted as MITRE certification, endorsement, or independent validation.

2. Foundational Threat Hunting Taxonomy

The following 20 categories constitute the initial IAIGCRM threat-hunting classification.

ID	Threat Hunting Category	Preliminary MITRE ATT&CK Association
TH-001	Authentication Anomalies	T1110 — Brute Force
TH-002	Privileged Account Activity	T1548 — Abuse Elevation Control Mechanism
TH-003	Lateral Movement Detection	T1021 — Remote Services
TH-004	Command-and-Control Communications	T1071 — Application Layer Protocol
TH-005	Data Exfiltration	T1041 — Exfiltration Over C2 Channel
TH-006	Malware Execution	T1204 — User Execution
TH-007	Persistence Mechanisms	T1053 — Scheduled Task/Job
TH-008	Suspicious Process Execution	T1059 — Command and Scripting Interpreter
TH-009	Network Scanning and Reconnaissance	T1046 — Network Service Discovery
TH-010	DNS Threat Hunting	T1071.004 — DNS
TH-011	Endpoint Integrity	T1565.001 — Stored Data Manipulation
TH-012	Insider Threat Indicators	T1098 — Account Manipulation
TH-013	Credential Theft	T1003 — OS Credential Dumping
TH-014	Ransomware Precursors	T1486 — Data Encrypted for Impact
TH-015	Web Application Attacks	T1190 — Exploit Public-Facing Application
TH-016	Firewall and Network Policy Violations	T1562.004 — Disable or Modify System Firewall
TH-017	Cloud Security Threats	T1078.004 — Cloud Accounts
TH-018	Threat Intelligence IOC Matches	Multiple techniques, dependent on observed behavior
TH-019	Defense Evasion and Log Tampering	T1070 — Indicator Removal
TH-020	MITRE ATT&CK Coverage and Threat-Hunting Gaps	Cross-technique coverage assessment

These associations provide initial analytical starting points. Individual reports may incorporate multiple ATT&CK techniques and require additional mappings following technical review.

3. Detection Engineering Methodology

IAIGCRM proposes a six-stage detection engineering lifecycle.

Stage 1 — Threat Hypothesis

Identify an adversarial behavior, associated security risk, and observable indicators.

Stage 2 — Telemetry Identification

Determine the required log sources, event fields, data quality, retention, and collection mechanisms.

Stage 3 — Detection Development

Develop SPL searches and correlation logic to identify behavior consistent with the hypothesis.

Stage 4 — Controlled Simulation

Generate representative activity in an authorized, isolated laboratory environment.

Stage 5 — Detection Validation

Evaluate whether the detection identifies expected activity, including false-positive and false-negative considerations.

Stage 6 — Reporting and Improvement

Document findings, detection limitations, ATT&CK associations, control coverage, and recommended improvements.

This lifecycle is iterative. Detection logic and telemetry requirements may be refined as additional evidence becomes available.

4. Standardized Threat Hunting Report Structure

Each report will follow a common specification:

1. Report identifier, title, version, and validation status.

2. Threat description and investigative hypothesis.

3. MITRE ATT&CK tactic and technique associations.

4. Required telemetry sources and data fields.

5. SPL detection and correlation logic.

6. Investigation procedures and supporting evidence.

7. Controlled simulation and validation procedures.

8. Expected observations and detection limitations.

9. False-positive and false-negative considerations.

10. Security control effectiveness assessment and recommendations.

5. Laboratory Research and Validation

Initial development will use an IAIGCRM research laboratory incorporating Kali Linux, Splunk Enterprise, Linux systemd journal telemetry, and controlled event-generation exercises.

The initial environment supports investigations involving administrative activity, system services, scheduled tasks, and selected authentication events.

Additional telemetry—including process execution auditing, network flows, DNS, endpoint security events, and cloud audit logs—will be introduced where necessary.

The existence of a detection query does not establish that its associated threat is fully detectable. Each report must identify its coverage boundaries and supporting evidence.

6. Detection Maturity and Publication Status

Each detection will receive one of four status classifications:

Status	Meaning
Proposed	Detection hypothesis and preliminary mapping documented
Under Development	SPL logic and telemetry requirements being implemented
Lab Validated	Defined test cases executed and results documented
Published	Reviewed and authorized for public release

A Lab Validated designation indicates successful evaluation against documented test cases, not comprehensive detection effectiveness against all possible adversary implementations.

7. Planned Research Deliverables

The initiative is expected to produce:

A 20-category threat-hunting taxonomy.
A reusable SPL detection and reporting library.
A MITRE ATT&CK mapping matrix.
Controlled simulation scenarios and validation records.
Security monitoring and control-effectiveness dashboards.
Research publications and practitioner training materials.

8. Research Governance and Version Control

The framework will be developed using the institute's established draft, review, authorization, packaging, and deployment process.

Taxonomy changes, ATT&CK mapping revisions, detection updates, and validation results will be version controlled.

Publication of the taxonomy does not imply authorization to publish all underlying laboratory configurations, datasets, or experimental materials.

9. References and Attribution

Primary technical references include:

MITRE ATT&CK — https://attack.mitre.org/
MITRE ATT&CK Enterprise Matrix — https://attack.mitre.org/matrices/enterprise/
Splunk Search Reference — https://docs.splunk.com/
NIST SP 800-61 — Computer Security Incident Handling / Incident Response Guidance
NIST SP 800-53 — Security and Privacy Controls for Information Systems and Organizations

MITRE ATT&CK is a knowledge base maintained by MITRE. IAIGCRM's proposed taxonomy is an independent research classification informed by that knowledge base.

IAIGCRM — Institute for AI Governance, Cybersecurity & Risk Management

Document Classification: Research Draft

Version: 0.1

Retention: Approved October 22, 2026

Publication Authorization: Pending Editorial Review