Somewhere in America, a police officer sat down at a terminal, typed in a license plate, and watched a map light up with everywhere that car had been for the past month. No warrant. No case number. The person being tracked was an ex-girlfriend. The system worked exactly as designed, and that is the whole problem. This is the part of cybersecurity that firewalls and patch cycles never touch: the authorized user who turns a legitimate tool into a weapon.

Security researcher Bruce Schneier flagged more than a dozen documented cases of police using the Flock automated license plate reader network to obsessively, and illegally, track specific people. None of these involved a hacker. Every one involved a badge, a login, and a search box that nobody was watching.

iRhythm digital health branding, referencing the company's confirmed data breach
iRhythm confirmed attackers stole patient data and demanded a ransom, a reminder that sensitive systems leak from inside and out.

The Breach Came With A Login

We spend enormous energy modeling the outside attacker. The brute-force attempts against the VPN, the phishing lure, the unpatched edge appliance. Those threats are real and you should keep blocking them. But the Flock cases expose a category most teams barely instrument: the person who is supposed to be there, doing something they are absolutely not supposed to do.

An automated license plate reader network is a surveillance database. So is an electronic health record. So is the cardiac monitoring data iRhythm just confirmed was stolen, a breach the company learned of on June 8 before attackers demanded a ransom. Whether the data walks out through an external intrusion or gets quietly queried by an insider with a personal grudge, the failure mode is identical: a sensitive system handed out information to someone whose access was never tied to a legitimate, reviewable purpose.

The uncomfortable truth is that most access-control systems answer the wrong question. They ask “is this person allowed to query the database?” They almost never ask “why is this person querying this specific record right now, and does that reason hold up?” A cop is allowed to run a plate. That permission says nothing about whether running his ex-wife’s plate forty times in a week is policing or stalking.

When The Logs Don’t Watch The Watchers

Here is what makes these stories a cyber security failure and not just an HR one. In nearly every documented Flock abuse case, the misuse was caught after the fact, often because the victim noticed, complained, and forced an investigation. The system held the evidence the entire time. The query logs existed. Nobody read them until the damage was already done.

That is the same pattern security teams keep repeating with their own crown-jewel systems. You collect audit logs because a compliance checklist told you to, you dump them in a bucket, and you never build threat detection on top of them. The logs become a forensic artifact for the post-incident report rather than a live control. Defense in depth means nothing if the deepest layer, the human with valid credentials, faces zero monitoring.

Think about what your organization actually watches. You probably have alerting on failed logins, on impossible-travel sign-ins, on malware execution. Now ask: do you have a single alert that fires when an authorized analyst pulls 500 customer records in an hour when they normally pull five? When a support agent looks up a celebrity’s account? When someone queries data for a region they have never worked? For most teams the honest answer is no, and that gap is exactly where insider abuse lives.

Practical Threat-Protection For Your Own Insiders

You can close this gap without buying a single new product. The work is policy, logging discipline, and a willingness to treat authorized access as something that still needs justification. Start with these immediate moves.

First, find your high-sensitivity query systems and confirm they log not just authentication but every individual lookup, with the who, the what, and ideally a reason code. If your CRM, health records, surveillance feeds, or admin consoles only log “user signed in,” that is your first security hardening project. A login event tells you nothing about a stalker; a query log tells you everything.

Second, turn at least one of those logs into an actual alert this quarter. Volume anomalies are the cheapest win: define a normal query rate per role, then flag the outliers for human review. You do not need machine learning. A scheduled job that emails the security lead when anyone exceeds a sane threshold catches the obsessive-searcher pattern that defined the Flock cases.

Third, require a reason for sensitive lookups and make it a field, not a vibe. Forcing a user to type a case number, ticket ID, or business justification before viewing a record does two things. It creates a paper trail, and it adds just enough friction that casual snooping stops feeling consequence-free.

Over the longer term, build periodic access reviews that look at usage, not just entitlements. Most reviews rubber-stamp “does this person still need access.” The better question is “did this person’s actual queries over the last 90 days match their job.” And rehearse the insider scenario in your incident response plan. A tabletop where the attacker is a current employee with full credentials forces different muscle memory than one where you are kicking out an external intruder. The containment steps, the legal involvement, the evidence handling, all of it changes when the threat carries a badge.

Frequently Asked Questions

Isn’t insider abuse an HR problem rather than a security one?
It is both, and treating it as only HR’s job is why it stays invisible until a victim complains. Security owns the logging, detection, and evidence-handling that make insider misuse provable, which is what turns a vague suspicion into an actionable case.
How is this different from classic data loss prevention?
DLP watches for data leaving the perimeter through email, uploads, or USB. The abuse described here happens entirely inside an authorized session, where a legitimate user simply views data they have no business reason to see. You need query-level monitoring, not just egress monitoring.

Sources

Take Control of Your Server Security

Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.

Secure. Automated. Lightweight.

Stay up to date with the latest news, releases and more.

Take Control of Your Server Security

Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.

Secure. Automated. Lightweight.