Comment by btown | Hacker News Reader

Comment by btown | Hacker News Reader

Parent Full thread

> The report says the system allows any authorized user to access all applications and data regardless of their clearance level or operational need. As a result, “Any user can potentially access and misuse sensitive” classified information, the memo states, with no logging to track their actions.

Given that segmentation of data access is a core part of the pitch (see e.g. https://www.palantir.com/docs/gotham) - if security controls were intentionally omitted from the prototype scope, that seems like a reckless scoping decision to make. And if security controls were unintentionally bypassed, this speaks to insufficient red-teaming of the prototype before launch.

I couldn't be more pleased that this is coming to light, though. Perhaps it opens decisionmakers' eyes to the dangers of over-centralizing military operations on a system that simultaneously allows operators to diffuse accountability to a semi-autonomous target-calling system, and is foundationally connected to surveillance-state systems tracking U.S. citizens. Entire genres of movies posit the negative outcomes of this kind of system on civilians and military personnel alike; they are cautionary tales to Not Create The Torment Nexus. Sometimes decentralized, human-in-the-loop, need-to-look-the-target-in-the-eyes operational coordination is a feature, not a bug.

I've worked on similar types of operational systems in the past. The access control is always extremely limited in the prototypes.

It is important to understand that the customers don't have a clear view of the types of access controls they want until they start field exercises. By having relatively limited access controls in the prototype, they discover in real use cases that allowing some data access which never would have occurred to them is highly valuable which can then be refined into specific types of data sharing. In a default locked down environment, these beneficial interactions would never be discovered because they can't occur. All of the ways the users access and use data in the prototypes is logged and studied.

Similarly, other types of data sharing expose real risks that can be reduced to specific scenarios developed during operational exercises. The problem with an exhaustive access control model is that it simply has too many degrees of freedom to be usable for most people.

During development, the universe of all possible uses of access control is reduced to a much simpler and more understandable model of the key data it is important to restrict and the key data it is important to share, grounded in real-world operational learnings. These models are simpler and more precise to implement, and also easier to verify the correctness of, than a default "access control all the things" approach.

> insufficient red-teaming of the prototype before launch

There's been no launch. It's a prototype.

« Enterprise security

We reject the notion of gating, pay-walling, or upselling core security controls like audit logging, single sign-on, and multi-factor authentication. Whether you’re a small business or a federal agency, you get access to every core enterprise security feature in our standard offering:

Mandatory encryption of all data, both in transit and at rest, that uses robust, modern cryptography standards. Strong authentication and identity protection controls, including single sign-on and multi-factor authentication. Strong authorization controls, including mandatory and discretionary access controls. Robust security audit logging for detecting and investigating potential abuse. Highly extensible information governance, management, and privacy controls to meet the needs of any use case. »

The real question is: did the product manager shave his beard?

developing secure software is very difficult. you have to start from a foundation of immutable data storage. then you need reproducible compilation from source code, to all executables, to bootable images. then you need out-of-band hardware that can verify signatures on the images being booted. all access to the system must take place through accounts with hardware tokens where all data access (r/w) is digitally signed and logged. then you need all developer access to the system to take place through this system. then at the application layer all data must be encrypted with unique keys, and the ownership and assignment of access to these keys must all be logged. this isn't something you can "bolt on later." it has to be a part of the platform architecture before development even begins.

Reply on news.ycombinator.com