A stolen or misused account usually still has valid permissions, so the strongest signal is often not what it is allowed to do but whether its activity looks like the people who do the same job. MITRE D3FEND names this countermeasure Job Function Access Pattern Analysis (D3-JFAPA) and defines it as "Detecting anomalies in user access patterns by comparing user access activity to behavioral profiles that categorize users by role such as job title, function, department." It sits under the Detect tactic as a child of User Behavior Analysis (D3-UBA) and analyzes the Authorization artefact. This card explains how peer group analysis works, which ATT&CK techniques D3FEND relates it to, where it is implemented, how to verify it and where it fails. It assumes the UEBA basics in the UEBA Guide.
Key takeaways
- Peers, not thresholds. D3-JFAPA compares a user's current access with a profile of functionally similar users, grouped by attributes such as job title, organisational hierarchy or department, rather than with a fixed rule.
- Peer group quality decides false positives. D3FEND's own consideration is the potential for false positives from anomalies that are not malicious, and its cited patent ties low false positive rates to accurate peer groups.
- D3FEND relates it to valid account abuse. Through the Authorization artefact, D3FEND infers a relationship to Valid Accounts (T1078) and External Remote Services (T1133), both modelled as producing an authorisation.
- HR and directory data are part of the control. Stale titles, missing departments and catch-all groups produce meaningless peer groups, so attribute hygiene is a prerequisite, not a nice-to-have.
- It suits human accounts best. Service accounts and other non-human identities have no job title; they are better profiled against their own history and their declared purpose.
D3-JFAPA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-JFAPA (d3f:JobFunctionAccessPatternAnalysis) |
| Tactic | Detect |
| Parent technique | User Behavior Analysis (D3-UBA) |
| Digital artefact | Authorization (D3FEND relation: analyzes) |
| D3FEND reference | Securonix Inc patent application US20160226901A1, "Anomaly Detection Using Adaptive Behavioral Profiles" (granted as US9544321B2) |
| Typical data sources | HR system or directory attributes (title, department, manager, location), group memberships, resource access logs, application and database audit logs, cloud and SaaS activity logs |
| Effort | Medium to high: needs clean identity attributes, months of baseline data and analyst tuning |
| Main limitation | An attacker whose actions resemble the victim's peers, or an insider whose whole peer group shares the risky access, does not stand out |
How it works
D3FEND's knowledge base article describes two steps. Peer group analysis first identifies functionally similar groups of actors, users or resources, based on categorisations such as job title, organisational hierarchy or another attribute that indicates similar job function. Current access activity is then compared with the matching peer group's behaviour profile to find anomalies.
The patent D3FEND cites adds the working detail. Peer groups can be built from inventory attributes and grouping rules and then refined using either granted access entitlements or actual logged resource access. Behavioural indicators are measured over fixed periods, for example transaction counts by hour and day of week for customer service staff, or concurrent users per hour and daily data volume per user for database monitoring. Profiles age with an exponential decay so they follow current behaviour (the patent's example uses a 14-day half-life), outliers beyond a probability threshold go to risk analysis, and normal observations update the profile.
- Static peer groups: defined from HR or directory attributes such as department, title or organisational unit. Easy to explain, but only as good as the attribute data.
- Dynamic peer groups: derived from shared memberships or behaviour. Microsoft Sentinel UEBA, for example, ranks each user's top 20 peers from security group membership, mailing lists and other associations, weighting smaller groups more heavily with TF-IDF.
- Hybrid: attribute groups for explanation, behaviour groups for accuracy, with an alert raised when both agree.
ATT&CK techniques D3FEND relates to D3-JFAPA
Relationship type: inferred only. D3FEND has no hand-made ATT&CK mapping for D3-JFAPA. In the D3FEND 1.6.0 ontology (checked November 2026), D3-JFAPA analyzes Authorization, and the techniques below are modelled as producing an Authorization, which is the basis of the inferred relationship. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Tactics (ATT&CK v20) | What peer comparison can surface |
|---|---|---|---|
| T1078 | Valid Accounts | Initial Access, Persistence, Privilege Escalation, Stealth | A legitimate account reaching resources, applications or data volumes its peers never touch |
| T1133 | External Remote Services | Initial Access, Persistence | Remote access by a user whose peer group does not work remotely, or through a service its peers do not use |
The same ontology also links the ICS matrix technique Valid Accounts (T0859) to the Authorization artefact. Defensive detail is in the MITRE ATT&CK T1078 Valid Accounts Guide and the T1133 External Remote Services Defensive Guide.
Where it is implemented
Products are listed as examples of each class and in alphabetical order; this is not a ranking.
| Implementation class | Example of how peers are formed (from vendor documentation) | Fits when |
|---|---|---|
| SIEM-integrated UEBA | Microsoft Sentinel UEBA: dynamically calculated peers, with peer fields in the BehaviorAnalytics ActivityInsights column such as ResourceUncommonlyAccessedAmongPeers and ActionUncommonlyPerformedAmongPeers (180-day baselines) and CountryUncommonlyConnectedFromAmongPeers (90 days) | Logs are already in the SIEM and identity data is synchronised |
| Standalone UEBA | Splunk User Behavior Analytics: behaviour-based account groups from login activity and AD events, plus HR peer groups and OU user groups defined from the HR data | You want peer modelling across many sources with a dedicated analytics engine |
| Insider risk and data security analytics | Peer comparison of data access and transfer volumes for defined user populations | The main concern is data theft by insiders |
| Application and database activity monitoring | Per-application profiles of which records, tables or transactions each role touches | A few high-value systems (finance, HR, patient records) matter most |
| Identity governance analytics | Entitlement outliers: users holding access their peers do not (granted, not used, access) | You want to remove outlier access before it is abused; see the Entitlement Catalogue Guide |
Implementation steps
- Fix the attributes first. Measure how many active users have a current department, title, manager and location in the HR feed or directory. Set a completeness target before switching on peer analytics.
- Choose the peer definition. Start with department plus job function for explainability; add dynamic or behaviour groups once you see where attribute groups are too broad (for example "IT" or "Contractors").
- Pick a small set of resources. Begin with systems where role-based access patterns are stable: finance applications, HR records, source code repositories, customer databases.
- Collect enough baseline. Plan for the product's documented baseline window (for Sentinel peer fields, 90 to 180 days); alerts during the first weeks are unreliable.
- Run in audit mode. Route peer anomalies to a dashboard, not the SOC queue. Review the top outliers weekly with the business owners, label true and false positives, and fix the peer groups behind repeated false positives.
- Combine before alerting. Promote to alerts only when a peer anomaly coincides with another signal, for example a new country, a privilege change or a large data transfer. A single peer outlier is a lead, not an incident.
- Handle movers. Feed joiner, mover and leaver events into the analytics so a transferred employee is not compared with the wrong peers, and so access kept from an old role is flagged.
- Roll back. If alert volume is unmanageable, revert to dashboard mode for the affected resources rather than disabling the model, so the baseline keeps learning.
Where identity fits
Peer analysis is an identity control at heart: it depends on accurate identity attributes and its output often leads to an access review, not only an incident. For non-human identities the job function idea translates poorly, because a service account's "peers" are rarely meaningful. Profile them against their own history and declared purpose instead, as described in the Service Account Behavioural Baselining Guide.
How to verify it works
- Controlled anomaly test: with approval, have a test account in one department access a resource only another department uses, then confirm the peer field or score changes and reaches the analyst view.
- Peer group review: quarterly, sample users and check that their computed peers make sense to their manager. Wrong peers are the most common hidden failure.
- Back-testing: replay known past incidents or insider cases through the model and record whether they would have scored as outliers.
- Coverage check: confirm every in-scope resource is still sending access logs; a silent log source looks like perfectly normal behaviour.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Active users with complete peer attributes | Above 95% | Peer groups are only as good as the data |
| Share of peer anomalies labelled true positive | Rising quarter on quarter | Shows tuning is working |
| Peer anomalies that led to an access change | Tracked monthly | Shows value even when nothing is malicious |
| Controlled anomaly tests detected | 100% | Proves the pipeline end to end |
| In-scope resources with healthy access logs | 100% | Missing logs hide anomalies |
Limits, bypasses and failure patterns
- Peer-blending: an attacker who studies the victim's normal work, or who only touches what the role already uses, stays inside the profile. Peer analysis does not replace least privilege.
- Whole-group risk: if everyone in a team can export the customer database, one member doing so is not an outlier. Fix this with entitlement design, see the Authorisation Models Guide.
- Catch-all groups: broad departments such as "Operations" mix very different jobs and flood analysts with false positives.
- Stale HR data: movers keep old titles, contractors have none, and the model compares people with the wrong peers.
- Poisoned baselines: an intrusion that is already active while the baseline is learned becomes part of normal. Ageing profiles help over time but do not remove this risk.
- Applying it to service accounts: forcing non-human identities into job function groups produces noise; use their own baselines.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2(12) Account Monitoring for Atypical Usage | Monitoring accounts for atypical use, the core purpose of peer comparison |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring, AU-6 Audit Record Review, Analysis, and Reporting | Analysing access records for anomalies |
| NIST SP 800-53 Rev 5 | AC-6 Least Privilege | Outlier access found by peer analysis feeds least privilege reviews |
| NIST CSF 2.0 | DE.CM-03, DE.AE-02, PR.AA-05 | Monitoring personnel activity, analysing adverse events, reviewing access permissions |
| MITRE D3FEND | D3-UBA, D3-JFAPA | Parent and technique |
Related countermeasures
- Resource Access Pattern Analysis (D3-RAPA): profiles access by resource rather than by role.
- Local Account Monitoring (D3-LAM) and Domain Account Monitoring (D3-DAM): account-level monitoring that complements peer analysis; see D3-LAM Local Account Monitoring and D3-DAM Domain Account Monitoring.
- User Geolocation Logon Pattern Analysis (D3-UGLPA) and Authorization Event Thresholding (D3-AZET): additional signals that make a peer anomaly worth an alert.
Practitioner checklist
- Measure and fix completeness of title, department, manager and location attributes.
- Start with a few high-value resources with stable role-based access.
- Allow the documented baseline period before trusting alerts.
- Run peer anomalies in dashboard mode and label outcomes before alerting.
- Alert on peer anomalies only when combined with another risk signal.
- Feed mover events into the analytics and flag access kept from old roles.
- Review computed peer groups with managers each quarter.
- Profile service accounts and other NHIs against their own history, not job function peers.
Standards and references
- MITRE D3FEND: Job Function Access Pattern Analysis (D3-JFAPA)
- Securonix Inc: Anomaly Detection Using Adaptive Behavioral Profiles (US20160226901A1)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (AC-2(12))
- Microsoft Learn: Identify threats with UEBA in Microsoft Sentinel
- Microsoft Learn: Microsoft Sentinel UEBA reference
- Splunk Docs: Review peer groups in Splunk UBA
Related NHI Mgmt Group resources: MITRE D3FEND Guide · UEBA Guide · Insider Threat Programme Guide · Service Account Behavioural Baselining Guide