zlacker

[return to "Flock Exposed Its AI-Powered Cameras to the Internet. We Tracked Ourselves"]
1. dogman+Sj1[view] [source] 2025-12-22 23:42:16
>>chaps+(OP)
Was fortunate to talk to a security lead who built the data-driven policing network for a major American city that was an early adopter. ALPR vendors like Flock either heavily augment and/or anchor the tech setups.

What was notable to me is the following, and it’s why I think a career spent on either security researching, or going to law school and suing, these vendors into the ground over 20 years would be the ultimate act of civil service:

1. It’s not just Flock cams. It’s the data eng into these networks - 18 wheeler feed cams, flock cams, retail user nest cams, traffic cams, ISP data sales

2. All in one hub, all searchable by your local PD and also the local PD across state lines who doesn’t like your abortion/marijuana/gun/whatever laws, and relying on:

3. The PD to setup and maintain proper RBAC in a nationwide surveillance network that is 100%, for sure, no doubt about it (wait how did that Texas cop track the abortion into Indiana/Illinois…?), configured for least privilege.

4. Or if the PD doesn’t want flock in town, they reinstall cameras against the ruling (Illinois iirc?) or just say “we have the feeds for the DoT cameras in/out of town and the truckers through town so might as well have control over it, PD!”

Layer the above with the current trend in the US, and 2025 model Nissan uploading stop-by-stop geolocation and telematics to cloud (then, sold into flock? Does even knowing for sure if it does or doesn’t even matter?)

Very bad line of companies. Again all is from primary sources who helped implement it over the years. If you spend enough time at cybersecurity conferences you’ll meet people with these jobs.

◧◩
2. skipan+MR1[view] [source] 2025-12-23 05:35:31
>>dogman+Sj1
As someone who has thought about, planned, and implemented a lot of RBAC... I would never trust the security of a system with RBAC at that level.

And to elaborate on that -- for RBAC to have properly defined roles for the right people and ensure that there's no unauthorized access to anything someone shouldn't have access to, you need to know exactly which user has which access. And I mean all of them. Full stop. I don't think I'm being hyperbolic here. Everyone's needs are so different and the risks associated to overprovisioning a role is too high.

When it's every LEO at the nation level that's way too many people -- it is pretty much impossible without dedicated people whose jobs it is to constantly audit that access. And I guarantee no institution or corporation would ever make a role for that position.

I'm not even going to lean into the trustworthiness and computer literacy of those users.

And that's just talking about auditing roles, never mind the constant bug fixes/additions/reductions to the implementation. It's a nightmare.

Funny enough, just this past week I was looking at how my company's roles are defined in admin for a thing I was working on. It's a complete mess and roles are definitely overprovisioned. The difference is it's a low-stakes admin app with only ~150 corporate employees who access it. But there was only like 8 roles!

Every time you add a different role, assign it to each different feature, and then give that role to a different user, it compounds.

I took your comment at face value but I hope to god that Flock at least as some sort of data/application partitioning that would make overprovisioning roles impossible. Was your Texas cop tracking an abortion a real example? Because that would be bad. So so bad.

◧◩◪
3. Punchy+Fz2[view] [source] 2025-12-23 14:10:28
>>skipan+MR1
It always starts with "we just give developers in project access to things in project and it all be nice and secure, we will also have separate role for deploy so only Senior Competent People can do it.

Then the Senior Competent Person goes on vacation and some junior needs to run a deploy so they get the role.

The the other project need a dev from different project to help them.

Then some random person need something that has no role for it so they "temporarily" gets some role unrelated to his job.

Then project changes a manager but the old one is still there for the transition

And nobody ever makes a ticket to rescind that access

And everything is a mess

◧◩◪◨
4. riskab+zV2[view] [source] 2025-12-23 16:47:57
>>Punchy+Fz2
...and "the fix" that companies usually resort to is "use it or lose it" policies (e.g. you lose your role/permission after 30 days of non-use). So if you only do deployments for any given thing like twice a year, you end up having to submit a permissions request every single time.

No big deal, right? Until something breaks in production and now you have to wait for multiple approvals before you can even begin to troubleshoot. "I guess it'll have to stay down until tomorrow."

The way systems like this usually get implemented is there's an approval chain: First, your boss must approve the request and then the owner of the resource. Except that's only the most basic case. For production systems, you'll often have a much more complicated approval chain where your boss is just one of many individuals that need to approve such requests.

The end result is a (compounding) inefficiency that slows down everything.

Then there's AI: Management wants to automate as much as possible—which is a fine thing and entirely doable!—except you have this system where making changes requires approvals at many steps. So you actually can't "automate all the things" because the policy prevents it.

[go to top]