The UEBA Illusion: Why “Total Visibility” Is A Dangerous Myth

3–5 minutes

At conferences and in boardrooms, everyone points to UEBA as the silver bullet for insider risk, fraud, and information security.

But the deeper I dig, the more I realise this view is dangerously incorrect.

While UEBA is a powerful processing engine, organisations often mistake its technical sophistication for total visibility. If we want to know if this technology actually meets your specific risk profile, we have to look past the vendor marketing.

To do that, we must understand the evolution of these systems, the specific use cases they were built to solve, and where they ultimately hit a ceiling.

Below, I have outlined the four key areas that define the reality of UEBA in 2026:

The Evolution: From Human To Machine

The industry focus on insider threats was catalysed by the 2013 Snowden leaks, shifting attention toward information compromise.

UEBA is the result of that shift. It is a high-dimensional data science engine designed to ingest massive volumes of telemetry and establish a baseline of “normal.” Gartner formally defined it in 2015 as an evolution of UBA, moving us from just tracking human logins to tracking “Entities” – servers, routers, and IoT devices.

The UEBA Maturity Timeline:

The UEBA Maturity Timeline

The Detection Ceiling: 8 Core Use Cases

Historically, UEBA is built for IT environments. To provide comprehensive insider risk coverage, it must address these 8 specific vectors:

  • IP Theft & Exfiltration: Monitoring the movement of sensitive intellectual property.
  • Fraud & Conflicts of Interest: Identifying anomalies or relationships in financial systems, transaction patterns, or data.
  • Internal Control Compromise: Spotting unauthorised “super user” creation or configuration backdoors.
  • Terrorism: Correlating HR “disgruntled” markers with internal communication sentiment analysis.
  • Espionage: Targeting “low and slow” data accumulation and “Whole Person” indicators (e.g., undocumented travel).
  • Workplace Violence: Using NLP on communication logs to detect hostility precursors.
  • Workplace Sabotage: Detecting virtual threats (encryption), OT (unauthorised access), and physical threats against critical assets.
  • Foreign Interference: Monitoring third-party accounts for lateral moves into sensitive domains.

The Critical Infrastructure Blind Spot

Here is where the UEBA illusion shatters.

There is a fundamental difference between a standard corporate office and a complex environment like infrastructure, high tech, or advanced manufacturing.

If turning off your building’s HVAC system only causes an inconvenience for your staff, UEBA alone is ideally suited for your business.

But if you run an airport, a medtech factory, or an electricity network? Traditional UEBA has a massive blind spot.

These environments require a “Multi-Domain” fusion of IT, OT, HR, Facilities, and Physical Security (PACS) data. An IT-only view cannot detect an operational sabotage event that originates with a wrench in the physical domain or the theft of samples from a laboratory freezer.

It lacks the context to see the “Whole Person” risk.

What Does “Good” Actually Look Like?

A mature insider threat detection capability is not bought in a box; it is built around your specific operating environment. “Good” requires a multi-domain solution capable of doing two things simultaneously:

  1. Detecting statistical anomalies in cyber / IT data.
  2. Executing scenario-based detection for Low-Probability, High-Impact (LPHI) kinetic events.

This multi-domain solution also needs to support the ‘8 Core Use Cases‘ outlined above as they relate to your organisation.

Scenario-based detection takes time and expertise to develop. My operational deployment process follows a strict methodology:

  • Identify: Start with the specific kinetic and digital risks and the critical assets.
  • Model: Develop detailed typologies for each scenario using intelligence analysis and threat modelling techniques.
  • Engineer: Build the detection logic using detection engineering methods.
  • Train: For LPHI scenarios, data availability is often minimal. You must rely on a rules-based approach or develop synthetic training data based on real-life scenarios and workplace monitoring.

The Bottom Line

Stop relying on generic IT baselines to protect critical infrastructure.

If your detection capability isn’t tailored to your specific physical and digital assets, you don’t have total visibility.

You just have a very expensive dashboard.

Further Reading

As published on LinkedIn.

DISCLAIMER: All information presented on PaulCurwell.com is intended for general information purposes only. The content of PaulCurwell.com should not be considered legal or any other form of advice or opinion on any specific facts or circumstances. Readers should consult their own advisers experts or lawyers on any specific questions they may have. Any reliance placed upon PaulCurwell.com is strictly at the reader’s own risk. The views expressed by the authors are entirely their own and do not represent the views of, nor are they endorsed by, their respective employers. Refer here for full disclaimer.

Operational Technology and Insider Threat Detection: What You Need to Know

8–12 minutes

3 Key Takeaways

  • Insider threats in operational technology (OT) environments can tank production, cause safety and quality incidents, and cripple your commercialisation pathway—often without leaving a digital trace.
  • Most insider threat programs are built for IT, not for OT environments with legacy equipment, safety risks, and fragmented data across OT and physical systems.
  • A smart detection approach—still emerging and adopted by only a few leading organisations—combines behavioural, scenario-based, and contextual signals across IT, OT, and physical domains to reduce risk without disrupting operations.

Insider Threats easily go unnoticed in Operational Technology (OT) environments

A few days ago, hackers opened the valve at Lake Risevatnet dam in Norway and no-one noticed for 4 hours (Security News Weekly). If a technician sabotaged your production line or quietly walked out with sensitive process data from your R&D facility, would you know? Would your systems flag it?

In my experience advising critical infrastructure and research-intensive companies, the answer is usually no. The maturity of cybersecurity in OT environments is backed up by a recent global study commissioned by Forescout (Takepoint Research). Insider threats are one of the most under-recognised risks in OT-heavy businesses. Unlike external hacks, insider incidents are often slow, subtle, and devastating. And they don’t just compromise data—they can damage physical assets, halt operations, and put lives at risk.

Unfortunately, most businesses are still using insider threat models built for IT environments. But OT (operational technology), where physical processes are controlled and monitored, is an entirely different beast. If your business depends on production, engineering, or commercialising proprietary research, it’s time to rethink how you detect insider threats—before it’s too late.


What Is an Insider Threat Program (and why OT gets left behind)

An insider threat program is a coordinated set of processes, technologies, and cultural practices to prevent, detect, and respond to harmful actions from trusted individuals—employees, contractors, vendors, or partners.

These programs typically include:

  • Policy and governance
  • Risk and asset identification
  • Monitoring and detection
  • Incident response and recovery
  • Training and culture

Problem is, most insider threat programs focus on IT environments. They monitor email, file transfers, login patterns, and endpoint activity. That’s all great, but in OT settings, insider threats play by a different rulebook.

In an OT-heavy business, critical systems might be unpatchable, unmonitored, or physically exposed. A contractor could swap out a device, reprogram a controller, or sabotage a process, and you wouldn’t see it in your SIEM or Quality Management System (QMS).

Worse, many companies treat OT, IT, and physical security as separate silos. That means no one has the full picture—and malicious insiders know it.


Insider Threat Risks in OT Environments

It’s not just OT environments that are different, the trusted insider risks are different too. Here’s some examples of what plays out in real incidents:

Risk CategoryReal-World Example
SabotageA maintenance worker disables sensors on a production line, causing costly downtime.
Data compromiseA disgruntled engineer uses a USB drive or other removable media to copy sensitive R&D data, which is subsequently leaked. In OT, USB devices are often used for legitimate tasks—making them a real risk for both data theft and malware introduction.
Theft (equipment / data)A contractor walks off-site with control modules or exports trade secrets via USB.
EspionageAn insider working for a foreign entity records processes and measures over weeks – the ‘know how’ you build into your processes is often a Trade Secrets which you haven’t patented, so you’re exposed.
Accidental / negligentA misconfigured PLC leads to an emissions breach and regulatory fines.
Credential compromiseA phishing victim gives attackers access to production systems. Phishing is not just an IT problem—it’s a leading cause of credential compromise in OT-heavy industries, providing a foothold for attackers into production systems.
Process disruptionA technician delays batch runs, quietly costing millions in lost output.
Physical safety risksA bypassed safety interlock leads to a serious injury on the shop floor. Integrating physical security data (badge logs, CCTV, visitor management) is crucial for correlating physical actions with digital events.

If you’re commercialising a new technology or scaling research into production, these aren’t just operational hiccups. They’re existential threats. They compromise intellectual property (IP), slow down time-to-market, and damage investor confidence.


OT detection is hard

Think of a real-world example. An power station detects a technician repeatedly accessing a substation after hours. Alone, it looked like overtime. But cross-referenced with badge logs, config changes, and HR notes? It could match a potential workplace sabotage scenario.

Unfortunately, OT environments like this example aren’t designed for visibility. Here are the 6 main detection challenges I see:

OT Detection ChallengeDescription
Legacy SystemsMany OT assets run on unsupported platforms that can’t be patched, monitored, or logged. They might also run proprietary protocols or custom integrations. Trying to install endpoint detection software? Good luck.
Mixed ConnectivitySome devices are air-gapped. Others connect via Wi-Fi or cloud APIs. You might not even know how many assets are online.
Fragmented DataAccess logs live in one system, telemetry in another, badge swipes in a third—with no correlation between them. To see the big picture, you need HR, physical security / facilities, IT and OT data in one place
Physical Access GapsUnlike IT assets, OT systems are often in physical spaces where people can tamper with hardware or override processes without leaving a digital trace. Many devices have no logging or remote monitoring. Integrating physical security data (badge logs, CCTV) is crucial for correlating physical actions with digital events.
Insider FamiliarityInsiders know your systems. They know the blind spots. They know when no one’s watching. If you’re only monitoring digital access or looking at corporate IT logs, you’re missing half the story. Don’t forget vendors and contractors, who often have privileged access.
Poor documentationMost orgs can’t trace how an alarm triggers a shutdown, and documentation for legacy systems might have been lost or poorly written. You might even find there’s no-one alive who can code in that language anymore!

This complexity means malicious insiders can chain actions together: badge in, disable a sensor, reboot a system, send a USB payload, walk away. If you want to understand how an insider could compromise your operation? You need to map attack paths across IT, OT, and physical layers.

So what can you do about it? Let’s start with detection.


Insider Threat detection that fits OT

There are 3 main approaches to detection in mixed IT / OT / physical environments. Whether you can use one or all of them depends on your capability maturity, available data, and technology stack on the one hand, and your inherent risk on the other.

Basic: Pattern-of-Life / Anomaly Detection

Many businesses start here. They look for simple red flags of what shouldn’t be happening, or what looks unusual. It’s a good starting point, and it’s where many corporate insider threat detection solutions start by looking at indicators out of the box, without being configured for your business

  • How it works: Builds a baseline of what “normal” looks like across users and devices. Flags deviations.
  • Good for: Stable operations with predictable activity.
  • Watch out for: False positives. No context. Easy to overwhelm your team.

Intermediate Advanced: Scenario-Based and Multi-Step Detection

In my experience there’s a big step up between basic and intermediate. This requires not only tools and data, but also people with different skillsets, such as intelligence analysis and data science. Achieving this successfully is much harder than it sounds.

  • How it works: Looks for sequences of actions that match known attack paths (e.g., badge-in → PLC access → config change).
  • Good for: Catching subtle or sophisticated attacks. Lower false positives.
  • Watch out for: Requires upfront work. Needs good integration.

This work goes by many names, but I use the term ‘typologies’ which is what we refer to in fraud and financial crime to detect a range of complex threats in a dataset. The global financial services industry invests millions each year in this capability to avoid huge fines.

Advanced: AI and Hybrid Models

Last is where AI takes us. I still see organisations using a mix of rule-based detection and AI. Also, there are some applications where you simply can’t use AI yet, such as to identify unknown unknowns or truly ‘novel’ threats. You still need a ‘human in the loop’ here:

  • How it works: Combines behavioural detection with scenario logic. Surfaces unknown patterns.
  • Good for: Dynamic environments with lots of data.
  • Watch out for: Over-alerting. Needs good context and tuning.

It’s worth noting many organisations are only at the start of the insider threat detection journey, so intermediate and advanced detection capabilities are still the exception, not the norm. However, a handful of advanced organisations are combining behavioural, scenario-based, and contextual analysis across IT, OT, HR and physical domains. They’re leading the way—helping develop the tools and methods to implement this at scale.


Detection-Driven Best Practices

Now you understand the problem we’re trying to solve, let’s talk action. Here’s what I recommend to every business trying to catch insider threats in OT:

  1. Map critical assets and who has access – You can’t protect what you don’t know. Prioritise systems with trade secrets, safety impact, or production value.
  2. Integrate cross-domain data – HR, IT, physical security, OT telemetry. Break down the silos.
  3. Use blended detection methods – Pair anomaly detection with scenario logic to balance breadth and depth.
  4. Segment networks and enforce least privilege – Don’t let operators access systems they don’t need. Limit shared credentials.
  5. Build OT into your incident response playbooks – Include safety, environmental, and operational contingencies.
  6. Train staff beyond cyber basics – Teach operators, engineers, and third parties how insider threats work—and how to report them.
  7. Continuously refine – Systems change. People change. Threats evolve. So should your models.

Final Word: You Can’t Protect What You Don’t Watch

If your business depends on operational tech, research, or manufacturing IP, you can’t afford to run blind.

Insider threats are rising. According to Ponemon, the average insider incident costs US$15.4M per year, but OT remains a blindspot for many organisations.

So here’s the question I always ask my clients: If someone inside your business tampered with a key process, would you know? Would your systems tell you? Would your people speak up?

If you can’t confidently say yes, it’s time to rethink your detection game.

Further Reading

DISCLAIMER: All information presented on paulcurwell.com is intended for general information purposes only. The content of paulcurwell.com should not be considered legal or any other form of advice or opinion on any specific facts or circumstances. Readers should consult their own advisers experts or lawyers on any specific questions they may have. Any reliance placed upon paulcurwell.com is strictly at the reader’s own risk. The views expressed by the authors are entirely their own and do not represent the views of, nor are they endorsed by, their respective employers. Refer here for full disclaimer.

Unlocking New Uses for your SIEM: Beyond Cybersecurity

7–11 minutes

3 key takeaways:

  1. Most companies are sitting on powerful analytics platforms like SIEMs—but rarely use them beyond cyber.
  2. There’s untapped potential to apply these tools to fraud, insider threat, IP protection, and compliance monitoring.
  3. With the right strategy, businesses can reduce compliance costs, improve visibility, and make better investment decisions.

Why this matters

Today’s risk environment demands more from businesses than ever before. Whether you’re protecting sensitive R&D, complying with complex regulations, or trying to prevent fraud, the traditional playbook is falling short. Organisations invest millions in security analytics. Frequently though, use of these tools happens in a silo, begging the question “can’t they do more?”. That’s a missed opportunity.

Many organisations already own high-powered Security Information and Event Management (SIEM) and observability platforms to give rich, real-time operational insights. In most businesses, there is no use of these tools outside of cybersecurity. That’s where this story begins.


The landscape: SIEMs, observability tools, and everything in between

Let’s unpack the main types of platforms:

  1. Security Information and Event Management (SIEM) – These platforms are the backbone of many security operations centres. SIEMs like Splunk, Sentinel, and Elastic collect and correlate security events to find and respond to threats in real time. They’re also critical for compliance reporting, audit trails, and forensic investigations.
  2. Observability platforms – Tools like Datadog, New Relic, and OpenTelemetry provide deep insights into how systems are operating. Used by DevOps and Site Reliability Engineers, they collect metrics and logs to monitor system health, performance, and prevent outages.
  3. Data lakes and warehouses – These centralised platforms are great for long-term storage and complex data queries. However, they often lack the speed or alerting capability needed for real-time risk response.
  4. BI dashboards and analytics tools – Platforms like Power BI and Tableau provide strong visualisation for decision-making. They focus on historical data, not real-time detection.
  5. Log management platforms – Tools like ELK store data for troubleshooting, but don’t get integrated into business processes.
  6. Application Performance Monitoring (APM) tools – Focus on user experience and technical metrics but often miss the business context needed for enterprise insights.
  7. Custom threat intelligence platforms – Powerful in capable hands, but often resource-intensive to maintain and inaccessible to non-technical teams.

Understanding how these tools work—and where they overlap—opens up new opportunities for extending their use into fraud, compliance, and continuous monitoring.


Non-cyber use cases hiding in plain sight

What became clear through my research is that many businesses are unknowingly sitting on a goldmine of data. This data can improve resilience, situational awareness and decision quality, resulting in reduced losses. Many tools already have access to the underlying telemetry. The gap is that organisations don’t translate their use cases into language or workflows these systems can use to solve business or compliance problems.

Here are a few real-world examples of how some organisations are using their existing telemetry platforms to solve non-security problems:

  • Fraud detection – One financial services firm used their SIEM to detect behavioural anomalies in user logins and transaction data. This helped identify fraudulent activity faster and reduce false positives in fraud alerts.
  • IP protection – A biotech set up observability pipeline alerts to detect unusual access patterns to protected research environments. This gave them a chance to intervene before valuable data walked out the door.
  • Insider threat monitoring – A large enterprise integrated HR systems with SIEM logs to flag when high-risk employees (e.g. those about to exit the company) accessed sensitive files, enabling pre-emptive action.
  • Physical security integration – A logistics company ingested building access logs into their SIEM to monitor for suspicious after-hours activity. This provided near real-time visibilty of threats in zones containing high-value or regulated assets.
  • Regulatory compliance – A US health services provider configured automated alerts to detect improper access to patient records. This streamlining HIPAA compliance and reporting, easing the burden on their audit teams.

These examples aren’t outliers. They represent what’s possible when organisations look beyond the traditional cyber perimeter and align technology with broader business risks.


Trade-offs and tricky bits

Of course, extending the use of SIEMs and observability platforms isn’t without its challenges. These are powerful tools, but were built with specific users and functions in mind. Repurposing them for broader use requires careful planning, stakeholder alignment, and a realistic view of limitations.

MetricConsiderations
Cost vs returnSIEM platforms, in particular, can become prohibitively expensive as more data sources are added. Every additional log source or telemetry stream can drive up ingestion costs, licensing fees, and infrastructure requirements. Businesses need to balance the value of added insights against escalating costs.
Expertise and resourcingMany of these platforms are complex and require specialist skills to configure and manage. Cyber teams are often already overstretched, they don’t have capacity. Asking them to support fraud, compliance, or operational use cases often requires cross-skilling or additional resources.
Data governance and privacyAggregating sensitive business data—such as HR records, payroll, or personnel movements—can raise privacy concerns. Any use needs to be aligned with data protection laws such as Australia’s Privacy Act, or the GDPR in Europe.
Tool mismatch and workflow gapsObservability platforms are fast, lightweight, and built for performance. But they’re not designed for legal defensibility, long-term retention, or audit-ready compliance reporting. SIEMs, on the other hand, are great for that. But, they can lack the ease of use or responsiveness that observability tools provide.
Redundancy and duplicationWithout coordination, multiple teams end up collecting and analysing the same data using different tools. This can lead to inefficiency and potential confusion around ownership and accountability. Worst case for regulatory compliance, you generate contradictory records which is a red flag to an inspector.
Table: Benefits and Challenges

Yes, there are challenges, but the opportunities are too great to ignore. Now’s the time for risk and compliance leaders seeking smarter, scalable approaches to assurance to speak to the CIO.


Real compliance benefits—if you play it right

Compliance is a growing cost centre for many organisations. Increasingly, fraud and protective security is becoming a regulated compliance program. Take Australia’s Privacy Act, Scams Protection Framework Act and Security of Critical Infrastructure Act as two examples. Teams are under pressure to meet complex compliance obligations, conduct audits, investigate incidents, and coordinate a response. Given most responses increasingly relate to compliance obligations, there’s a regulatory imperative to get this right. They’re often using manual processes and disconnected systems to do this, taking time, effort and higher chance of errors.

This is where SIEM and observability platforms can play a much bigger role. By automating key controls organisations can reduce the manual workload on compliance and audit teams. Examples include detecting access to sensitive data, validating privileged user activity, or monitoring export-controlled environments. The result? Improved productivity, cost control, and compliance. Dashboards and real-time alerts eliminate the need for manual reviews, reduce investigation time, and improve coordination across the business.

These platforms also provide strong evidence for legal and regulatory inquiries. For example, access logs and alert histories makes it easier to prove data segregation or show controls were in place. This supports compliance SOX, the Privacy Act, or Australia’s Security of Critical Infrastructure Act (SOCI).

These tools allow compliance teams to shift from reactive policing to proactive risk reduction. In turn, this makes them more efficient, more strategic, and more valuable to the business.


What business leaders need to do next

This isn’t just a technology issue—it’s a business opportunity. Executives should be asking how they can leverage their existing technology investments to solve new problems.

Here’s a five-step path to get started:

  1. Audit your existing tools – Inventory the telemetry and analytics platforms already in use. Identify whether you have a SIEM, an observability platform, or both. Are you using these to good effect?
  2. Map broader risks – Work with fraud, HR, IP, and compliance stakeholders to identify high-impact, high-cost business risks. Identify use cases that benefit from automation and real-time monitoring.
  3. Engage privacy and legal early – Involving these teams from the outset. This helps prevent delays later and ensures any solution aligns with data protection laws and internal governance frameworks.
  4. Pilot a use case – Choose one low-risk, high-impact use case (e.g. unusual access to critical systems) and configure alerts or dashboards using existing tools. Track the cost, value, and effort involved.
  5. Build the business case – Quantify what value these solution will save in hours, cost or loss reduction, or productivity. Present this in a way that links directly to business strategy and financial performance.

If you’re already paying for the Ferrari, why are you only using it for trips to the supermarket? With a little tuning and creativity, you can unlock value across new use cases without buying yet another tool.


Further Reading

DISCLAIMER: All information presented on PaulCurwell.com is intended for general information purposes only. The content of PaulCurwell.com should not be considered legal or any other form of advice or opinion on any specific facts or circumstances. Readers should consult their own advisers experts or lawyers on any specific questions they may have. Any reliance placed upon PaulCurwell.com is strictly at the reader’s own risk. The views expressed by the authors are entirely their own and do not represent the views of, nor are they endorsed by, their respective employers. Refer here for full disclaimer.