Knowledge is Power
BARE METAL CYBERKnowledge is Power

Sitewide Search

Search Bare Metal Cyber

Search courses, individual lessons, wiki entries, books, podcasts, magazine articles, Daily Cyber News, and Darwin.

MITRE D3FEND™ Learning Center

D3-ANET — Authentication Event Thresholding

Collecting authentication events, creating a baseline user profile, and determining whether authentication events are consistent with the baseline profile.

2Mitigation mappings
1Parent technique
1Related artifact
5Source references

Detect · D3FEND ontology 1.6.0 · Active

Open official technique ↗
Official D3FEND definition

Definition

Collecting authentication events, creating a baseline user profile, and determining whether authentication events are consistent with the baseline profile.

Official D3FEND knowledge-base content

How it works

Authentication event data is collected (logon information such as device id, time of day, day of week, geo-location, etc.) to create an activity baseline. Then, a threshold is determined either through a manually specified configuration, or a statistical analysis of deviations in historical data. New authentication events are evaluated to determine if a threshold is exceeded. Thresholds can be static or dynamic.

Actions

As a result of the analysis, actions taken could include:

  • [Account Locking](/technique/d3f:AccountLocking)
  • Raising an alert

Example data sources

  • Directory server logs
  • VPN Server logs
  • IDAM Capability logs
  • NAC logs
  • Authentication client logs
  • Kerberos network traffic
  • LDAP network traffic

Considerations

This technique covers statistical outliers. Though depending on the complexity or dimensionality of the data considered, outliers may not be obvious to a human analyst reviewing events in simplistic analytic views. If the malicious activity is not statistically different from benign activity, an alert threshold will not be met.

Bare Metal Cyber interpretation

Implementation perspective

Authentication Event Thresholding 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 the relevant system, activity, and evidence sources.

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.

Ontology hierarchy

Technique hierarchy

Direct child techniques

None listed at this level.

D3FEND graph relationships

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

analyzesAuthentication
Curated D3FEND mapping

ATT&CK Enterprise mitigation relationships

These links come from the D3FEND ontology’s ATT&CK mitigation mapping. They help users navigate between the knowledge bases and do not guarantee mitigation effectiveness.

M1036Account Use PoliciesRelatedM1040Behavior Prevention on EndpointRelated

D3FEND note: D3-AZET may be related (is potentially related though not called out in ATT&CK definition.)

Source record

Authoritative sources

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.