I’m asking you to give me 6 minutes of your time to read this. I promise it will be worth it.

Allow me to start with this:

According to Cybersecurity Insiders’ 2024 Insider Threat Report, 83% of organizations reported at least one insider attack in the past 12 months guardtime.com+6ibm.com+6securonix.com+6.

These are reported thefts. Of course, they don’t include thefts that went unreported because the victim never found out that they had been robbed, or thefts that needed to remain private.

Bottom line: Every one of you have probably been robbed of at least some of the secured intellectual property or other valuable information in your repository. And 83% of you know it.

That said…

PRELUDE - THE APPLE INCIDENT

You may have already heard something about the former employee at Apple’s Vision Pro division who stole an astonishing amount of confidential and classified material before leaving the company. What happened could have been an advertisement for our Guardian (or Defense for eDocs). The only problem? No one would have believed something like this could happen to a company like Apple. Not after Edward Snowden. Frances Haugen. Jack Teixeira. Harold Martin, The Panama Papers, The Pandora Papers, Harold, SONY Pictures,,…

After all, Apple has internal security systems intended to detect employees accessing or downloading unusual volumes of documents or copying them from a company network to individual devices.

WHAT HAPPENED?

Di Liu, a senior product design engineer on the Vision Pro team, was employed at Apple from September 2017 until November 2024. In his final weeks—while secretly having accepted a job with Snap—he manually downloaded a “massive volume” of internal files (design schematics, supply-chain data, testing results, and unreleased feature documentation) to his personal cloud storage, even renaming and deleting them on his Apple-issued laptop. Apple discovered the breach through forensic analysis, reviewing audit logs that showed what he accessed, moved, and removed, which triggered a lawsuit filed on June 24, 2025.

Liu used valid credentials to access a wide array of sensitive materials, many of which were unrelated to his job responsibilities. The breach wasn’t the result of a hack or technical failure—it was the result of a trusted insider misusing legitimate access without being flagged.

To be clear, and as stated previously, Apple did have several standard security tools in place. These included access controls, user authentication, internal audit logs, data classification, and post-incident forensic capabilities. The audit trail ultimately allowed Apple to identify what was taken and when, and legal agreements such as NDAs gave them grounds to pursue civil action. However, these tools were all reactive. They helped Apple understand the scope of the theft only after it had already occurred—but they offered no protection against the theft in progress.

This highlights three critical security failures. First, Apple’s permission model lacked the enforcement of role-based access control. Liu should never have had access to many of the files he downloaded. Second, and more importantly, Apple had no real-time activity monitoring in place. The theft occurred over multiple days, with no automated alerts, no triggered lockouts, and no behavioral thresholds to raise red flags. Everything Apple used to detect the theft—forensics, audit logs, legal action—came only after the fact. Third, Apple relied too much on trust, without verification.

They learned about the theft well after the thief had left, after the information was gone, and the damage was done. After all the millions they spent on security tools, the manpower invested, the staff monitoring these tools, they believed that they were doing all they possibly could. And then one man destroyed the myth that they were secure, and they paid the price for their complacency.

One last point worth emphasizing—something nearly every organization is guilty of—is an over-reliance on trust. We all want to believe that the people we work with, or those who work for us, will do the right thing. But trust alone isn't a security strategy. It’s not offensive or paranoid to verify that trust isn’t being exploited - it’s responsible. And the most effective way to do that is with Activity Monitoring.

MAY I BE YOUR HERO?

If you’re saying "If it can happen to Apple, it can happen to anyone, including me, but we have logs to go back to when it does?", "I'm doing all I can", "it’s inevitable, and we just need to plan for when it happens", I will listen, knowing that I have a solution right here in my electronic briefcase that I can take out and hand to you. It's the missing link to close the security hole that allowed Liu to walk out the door, It's Activity Monitoring - watching over users while they work, immediately alerting you when someone is trying to rob you ,and even disabling an account when necessary.

Tears of joy stream down your face, and you inevitably say “If I have anything else to sell you, I’ll buy it. You are my hero.”

Have you heard about WincTools?

For more details, read on.

Bottom of Form

INTERNAL INFORMATION THEFT PROTECTION FOR DUMMIES

There are three core approaches to protecting information inside corporate content repositories: Behavioral Analytics, which looks for suspicious patterns over time; Activity Monitoring, which tracks and responds to user actions in real time; and Hybrid Systems, which combine both approaches to detect anomalies while also providing real-time intervention when predefined thresholds are crossed.

Any of these approaches can either be organization-wide or application-specific. An organization-wide approach monitors behavior across all systems and applications, providing centralized visibility but often missing system-specific context. Application-specific monitoring, by contrast, operates directly within the system that holds the data, offering more precise alerts and real-time protection where it matters most.

When it comes to OpenText Content Management like eDocs, organization-wide solutions have two major limitations that are dealbreakers. First, they often have no visibility into what specific activities users are performing inside the application. Second—and more critically—they may not even know who the user is. With eDocs, some accounts are linked to network IDs, many are not. And because it uses a middle-tier architecture, it's the system account (like DM Server) performing the operations—not the end user directly.

This creates significant blind spots. Organization-wide tools that monitor file access often see every action as coming from the same service account, making it impossible to trace activity back to the real user. In some cases, they may even flag the DM Server itself as suspicious.

Even if the user could be identified, these tools typically lack the context to distinguish between different activities such as a document checkout, an export, a view, an email, or an edit. And not all edits are the same—some are performed in-place, while others involve a checkout that creates a local copy on the user's device. That local copy is not encrypted and, once it exists outside the repository, it is no longer governed by the internal application’s security model. Access rights tied to users or groups—such as who is allowed or denied access—are lost entirely when the document resides on a local drive. These documents could remain on the local machine for as long as the Force Cleanup allows (a minimum of one full day), completely exposed; but they are also available for a theft that could go undetected without a way to keep track of them.

The only reliable way to protect a repository is with an application-specific solution that understands how the platform works, what the activities mean, and how to respond appropriately when activity crosses the line.

THE ANALOGY

Your family is taking a pill that will tell you if you get COVID.

I am offering you a pill that will prevent COVID.

THE FULL STORY

Let’s imagine that I are on a conference call with you, and the recent employee theft at the Apple subsidiary Vision Pro comes up. I casually ask “So, what are you doing to prevent employee theft at your place?”

There are two probable answers.

“As far as I know, nothing.”

Or

“Our organization already has a system.”

If that solution is enterprise-wide, it’s probably Behavioral Analytics. Some may include limited Activity Monitoring, but it is typically generic and not geared toward application activities, especially when multiple applications are integrated (like SAP and Content Management).

My question to you: If Behavioral Analytics is all an organization needs to prevent employee theft, then why do we keep hearing about all these employee thefts?

Even after we know that Behavioral Analytics is not enough, why aren't more organizations rushing to seek out a solution that can really work - Activity Monitoring?

There are probably many reasons, including lack of awareness, but I think you might find this one amusing, but true.

It's just too damn simple. It can't possibly solve the complex problems of internal information theft inside an Enterprise System if it's this simple.

TOO SIMPLE?

Unlike Behavioral Analytics solutions, it doesn't require enormous development resources and hundreds of millions of lines of code. It doesn't use multiple parts from multiple sources written by multiple developers in multiple countries in multiple languages. It doesn't take an MIT graduate to install it, configure it, and use it. It doesn't require an enormous team of analysts to evaluate the results.

It's a tiny little service that runs on the SQL Server, and a simple little interface where you set everything up and review the activities of someone whose account is disabled.

Please don’t get me wrong. If it were that simple, why hasn’t anyone else done it? The fact is, it’s incredibly complex on the inside, especially when one of the goals was to make it simple to use.

Imagine this:

We have a customer with 10,000 employees. They’ve just spent millions on a company-wide Behavioral Analytics system. They’ve got dashboards, heat maps, predictive models… and then someone they trusted, who flew under the radar, who’s behavior appeared perfectly normal, still betrayed them and walked out the door with all the confidential documents in your EDRMS system that his job entitled him to. They’re left scratching their heads, wondering what went wrong.

Then I come along and say, “What you really need is to add Activity Monitoring.”

“Why is that?”

“Because it can catch a thief in the act. It’s constantly monitoring end-user activities, and as soon as a user exceeds a threshold, alerts are sent, and the account can even be disabled.”

Skeptical, they ask, “What’s involved?”

“It takes about 30 minutes to install. An hour or so to configure. An hour to train your people.”

“What’s involved in the implementation?”

“You answer these questions:

• What users should I monitor?
• What activities should I monitor?
• At what point do I want to be notified? At what point, if any, should a user be disabled?
• Who should receive the notifications?
• What should I order for lunch?”

“What’s the cost?”

“A fraction of what you spent on your Behavioral Analytics solution that didn’t stop the theft.”

“Ongoing Maintenance?”

“Practically nothing. Someone to add/change/remove the rules, someone to review the activities of a user who is disabled, someone to review the rules, and someone who manages the servers to monitor the service”

Is it too simple to be taken seriously? It can’t possibly be Enterprise ready and do everything I say it does. And yet—it works.

A LITTLE HISTORY

Long before Snowden, I wrote a stored procedure for a midsize law firm concerned about attorneys leaving and taking documents with them. Every 15 minutes, it scanned recent user activity on secured documents for a list of activity types and sent SQL Mail alerts when thresholds by count within the past hour were exceeded. It was a few hundred lines of code. Later I added a second threshold to disable a user in the PEOPLE table, and modified the email notification to mark it as Urgent and advise the recipient to refresh the DM Server caches immediately (to apply the user disabling).

And then when Snowden came out, I realized my little stored procedure could have stopped him.

And so, that basic concept became Guardian.

(Sidebar: Yes, our Guardian is named after the newspaper that gave me the idea.)

THE DIFFERENTIATOR – APPLICATION SPECIFICITY

One reason Activity Monitoring with Guardian (and Defense for eDocs) are so powerful is that they work within the framework of the application’s environment. As noted previously, this is important for two reasons: (1) they recognize the meaning of each activity type, and (2) they recognize the user who is passing the request through the middle tier. The first allows for granularity in defining the activities to monitor, while systems without it lump all activities that touch a document together. The second is important when there is a middle tier, since to the system it is that service making all the requests.

Several years later our Guardian is a lot more complex (on the inside). The original version was based solely upon activity counts within a timeframe, but our clients (especially the larger ones) found that counts were mostly ineffective, cumbersome to maintain, and impossible to get right. So, we went back to the drawing board and added analytics that measured activities based upon a user’s behavior. Activity Monitoring combined with Behavioral Analytics. But regardless, it's still a simple, inexpensive solution. Too simple and too inexpensive, I suppose. Perhaps we should charge more, throw in some blockchain buzzwords and a few dozen acronyms, and watch the demand skyrocket.

TAKEAWAYS:

• Employee theft of information is a five-alarm fire
• Behavioral Analytics alone will not pull the fire alarm to prevent employee theft.
• Activity Monitoring will.
• If you have eDocs, you have two solutions for activity monitoring. You have our Guardian, and you have Defense from OpenText.
• Pick one and make sure every client uses it.
• Of course, I'd prefer that your clients use our Guardian, but I'd rather they use Defense than do nothing.

CONCLUSION

I hereby give permission to any OpenText user to steal this document.