Notifications
Clear all
Topic starter
02/08/2026 11:53 am
TL;DR: Insider incidents are often driven by negligence, compromised credentials, and third-party access rather than pure malice, and IBM reports 83% of organisations saw insider attacks in 2024. Static thresholds in legacy SIEM and first-generation UEBA create noise that hides real risk, while context-aware analytics better separate normal activity from compromise and misuse.
NHIMG editorial — based on content published by Exaforce: The Call Is Coming from Inside the House: 6 Strategies for Insider Risk
By the numbers:
- 83% of organizations reported insider attacks in 2024.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.
Questions worth separating out
Q: What breaks when insider risk detection relies on static thresholds?
A: Static thresholds break because they treat all users as if they behave the same way.
Q: Why do compromised accounts make insider risk harder to detect?
A: Compromised accounts are hard to detect because the attacker uses valid credentials and inherited access, so the session looks internal even when the intent is external.
Q: How do organisations know whether insider threat controls are actually working?
A: They should look for reduced standing privilege, faster revocation after role change, better session traceability, and fewer unexplained data movement events.
Practitioner guidance
- Implement role-aware insider baselines Build baselines by user role, peer group, and historical behaviour so the SOC can suppress expected activity and escalate only genuine deviations such as unusual repository cloning or mass downloads.
- Correlate identity and SaaS telemetry Join authentication events, SaaS activity, source control actions, and DLP labels so a valid login cannot hide data movement or sabotage inside ordinary collaboration workflows.
- Audit dormant and offboarded access paths Review contractor accounts, stale employee profiles, and unused admin permissions to remove identities that no longer have a business need but still retain internal reach.
What's in the full article
Exaforce's full article covers the operational detail this post intentionally leaves for the source:
- The specific insider-risk workflow pattern behind the vendor's context-aware AI SOC approach
- Examples of how the article distinguishes careless users, compromised accounts, and third parties
- The four immediate hardening steps the vendor recommends for insider-risk posture
- How the vendor frames multi-model AI for detection, triage, and response in practice
👉 Read Exaforce's analysis of six insider-risk strategies and context-aware AI SOC design →
Insider risk detection in SaaS and IaaS: what teams are missing?
Explore further
02/08/2026 1:02 pm
Static insider rules are now a governance liability, not just a detection gap. The article is right that threshold-based logic generates noise, but the deeper issue is that static rules assume context is stable. In SaaS and IaaS environments, context shifts by role, project, and data sensitivity, so security programmes that do not model identity behaviour create blind spots. That makes the detection problem an IAM and analytics problem at the same time, and a mature insider programme must treat context as a control, not a tuning parameter.
A question worth separating out:
Q: Who is accountable when a third-party identity is used in an insider incident?
A: Accountability is shared across the business owner, the IAM or identity governance team, and the security function. If the access was not time-bound, reviewed, and offboarded correctly, the failure sits in lifecycle governance as much as detection. External identities need explicit ownership, not informal trust.
👉 Read our full editorial: Insider risk programs fail when static thresholds replace context
