Definition
Operating system level mechanisms to prevent abusive input device exploitation.
How it works
Input Device Hardening techniques filter certain commands, or disable related operating system functionality.
Analytics
All of these values can be analyzed and compared to a baseline:
Context can also include:
- Amount of input
- Duration of a single input
- Durations between inputs
- Value of input
- User which is logged in, to include attributes such as physical location of the user
- Date and time
- System which is processing the input
- Source device of input, to include its properties (eg. manufacturer), configuration (eg. keyboard layout) and behavioral attributes of this device (eg. first use)
- Source system of input (local or remote system)
- Other hardware devices attached to the system
Actions
Actions can include:
- Disabling the source device
- Sending an alert
- Locking the current session (eg. system screen lock, or returning to an authentication screen in a web app) and requiring one or more methods of authentication to continue
- Administratively disabling credentials for the account or the entire account -- the technique *Account Locking*
Examples
A malicious input device sends many keystrokes with approximately the same delay between each. This does not match the normal cadence of input, and the device is disabled.
Input to type the session user's name takes abnormally longer for each keystroke. The system is locked to the password prompt screen.
A system receives key press events from two different devices -- one device sends keystrokes after the other has been idle for a long time.
A system receives physical input in a user session, while that user has sent input from a device located out of the country in the past hour.
Network traffic is suddenly routed through a new external device, and nearly the same volume of network traffic is subsequently sent out the previously existing interface. The new external device is disabled, and an alert is raised to investigate the network configuration for a potential compromise.
Considerations
Given some example of legitimate behavioral input patterns, attackers could mimic those input patterns, a technique which has been used in popular culture in the creation of Deepfake videos and [This Person Does Not Exist](https://thispersondoesnotexist.com).
Implementation perspective
Input Device Analysis should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes Input Device.
Use the technique to identify suspicious, unauthorized, or abnormal activity through observable evidence and repeatable analysis.
Questions to ask
- Which events, states, or artifacts must be observed for the analysis to work?
- What analytic logic, threshold, comparison, or signature turns observations into a finding?
- How are expected false positives, blind spots, and environmental variations documented?
- Who receives the result, and what action is expected when the technique produces a finding?
Evidence and validation
- Telemetry and data-source configuration records
- Analytic logic, thresholds, signatures, and version history
- Test cases demonstrating expected positive and negative results
- Alert, triage, escalation, and tuning records
Common failure patterns
- Required telemetry is missing, delayed, or transformed in a way that invalidates the analysis.
- The technique produces alerts without an accountable triage and response process.
- Detection coverage is claimed from product deployment without testing the relevant analytic behavior.
This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.
Technique hierarchy
Top-level family
Parent techniques
Direct child techniques
None listed at this level.
Artifacts and ontology entities
These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.
Explicit technique relationships
Show inferred artifact relationship paths (1)
Offensive-technique relationships
These relationships are generated from D3FEND graph paths and are explicitly experimental. They should be treated as hypotheses for defensive analysis—not as proof that the technique prevents, detects, or removes an offensive behavior.
Authoritative sources
- Open this technique on the official D3FEND website ↗
- Open the official ontology resources ↗
- Continuous authentication by analysis of keyboard typing characteristics ↗Bradford Univ., UK · S.J. Shepherd · AcademicPaperReference
- Keystroke Dynamics ↗Biometric Solutions · Biometric Solutions · InternetArticleReference
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by The MITRE Corporation. MITRE D3FEND™ and the D3FEND logo are trademarks of The MITRE Corporation. MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Use of D3FEND source material is subject to the official Terms of Use.