We've learned nothing from the SolarWinds hack

I want to get there, but I also don't trust anyone except (maybe) myself to determine what capabilities are "good" versus "bad".

I literally just spent most of today messing with my 2018 Samsung TV trying to get rid of the bloatware they pre-installed. I had to do that because the apps took up 96% of the storage within. These apps cannot be deleted normally.

If we're heading towards a place where vendors are the ones deciding what users are allowed to do, as well as what the software is allowed to do, and at what level of granularity, I have no reason to trust them any more than I trust a russian state-sponsored hacker.

The proposed solution - 'run software in a way where we don't really care if it has a vulnerability, because it will happen' - is close to reality, but not quite there. The reality is that no matter how good our technical solutions are, trust ends up being a people problem, which means that compromises of that trust are going to happen. No matter how fine grained your capability based system is - if a system has the capability to do anything, then you're going to suffer loss when it is compromised. If a system gets compromised or corrupted and you don't care, then it's not a system you were using for anything useful in the first place.

While capability based systems are another important part of the solution, I would counter-propose that what we're actually looking for is compartmentalization. Acknowledging the reality that parts of our system are going to be compromised, and we are going to suffer some loss when that happens, carefully controlled capabilities can help scope that blast radius of compromises.

If we can't change that, what hope we have for a sane small-kernel capability-based system?

The security game is just too fast paced for a profitable business. Until we reach the point where it makes financial sense to move slowly and take extra time to ensure critical business systems are secure, nothing will be fixed.

If you have been an iOS developer since 2012, I'm sorry you had to go through that, but your extra work has been profoundly important to the privacy and security of mobile OSes. I'd like to see that same principled energy brought to desktop and server OSes.

Or, demand the EU let you side-load so you don't have to bother.

I wonder if there's enough demand for a service like this to be viable. Bundled with a universal package manager, signed and verified binaries, caching mechanisms, etc.

pypi: "YOLO, let us deprecate signatures!"

What the author wants is unrealistic and their understanding of detections isn't ideal. I assume they know that a SIEM doesn't need agents. But an EDR does. EDR can be a well configured auditd/sysmon and a response agent. Or you pay up and get a "nobody gets fired for buying crowdstrike".

One reality is that APT hacks are out of scope for most orgs.

Another reality is that for at least a decade and a half the security industry has accepted that prevention is not a good strategy against APTs. This is why you need that other EDR agent and SIEM. You focus your detection on what the threar actors do after compromise and around your important data. For most APTs this is effective but it is far from perfect. The biggest problem is people like the author who are not seeing actual compromises happen all the time.

Security costs money and it can only cost as much as the risk tolerance of the company. It can't cost so much that the company's profit margins take a beating for example. That's why NIST recommendations are important, so execs can say we are spending enough.

Another side of prevention is that it needs to be as invisible as possible. If users notice it or it gets in their way, by default it is bad, you have to do things to compensate for the deteriorated user experience. You can add MFA for example but better make up for it by making it a yubikey and doing SSO.

Keep in mind that corporate networks are a hodge-podge patchwork of random things pieced together over time. Threat actors need one mistake to abuse. And the P in APTs mean they'll try until they find the mistake, it's their day job quite literally lol.

The questions that we have to answer are heavily focused on the assumptions that we:

1. Have a network. 2. Have a physical premises. 3. Don't use API keys.

I'd happily attest to using AWS IAM properly. I'd happily be told that we aren't using it properly and asked to make changes.

https://xkcd.com/2030/

> I don't quite know how to put this, but our entire field is bad at what we do, and if you rely on us, everyone will die.

Full disclosure, I am a member of the steering committee for in-toto and the CEO of TestifySec which is the main contributor to Witness.

That's about as likely as everyone agreeing on a good, standardized operating system architecture, API, and driver model that also happens to be Written In Rust™ for good measure.

I wonder if one could do better by using a HackerRF and spy on LTE+WiFi communications. You wouldn't need to decrypt them, just identify how many different devices there are.

That other approach is to rely on confidential computing technologies, in particular, the remote attestation capabilities of Intel SGX and AMD SEV. These technologies are often associated with DRM or multi-party computation, but they can be used in a different way. In this alternative use case you statically attach a remote attestation to a piece of data as a signature of computation.

A signature of computation is a proof that a piece of data was derived by running a specific program with a specific input. If that program is deterministic, and has been verified by yourself or a third party, then it means the correctness of the transform can be mechanically verified in such a way that it's much harder to hack. In particular if you use SGX then root exploits on the machine doing the computation won't help the attacker due to the hardware level protections. If you use SEV it's harder but can AFAIK still be done with some specialized OS hacking.

Concretely this means that a shipped software artifact could come with a signature proving not only the identity of the developers, as is the case today, but that those files were produced using a known third party compiler and linker applied to e.g. a source tree at a specific git commit hash. Because those files can be verified by anyone including the developers themselves, it means that a compromised CI system is very limited in what it can do: every file has a cryptographic proof tracing it backwards to the input source tree, which in turn is replicated independently on developer's workstations and laptops so it can be checked by many semi-independent actors. And for extra value the company can hire a third party auditor who verifies that the source code at hash X does in fact meet the vendor's description of what it does.

I've experimented with this sort of approach in the past, but unfortunately CC as a tech gets sort of repeatedly stuck in the domain gap between low level systems programmers and the kind of wideband ecosystem building you need to deliver genuine business value. People aren't aware of what it can do or how to use it.

Also, this approach has a subtle side effect: it means the compiler is now a valid target for attack. For example if source code can corrupt compiler internals sufficiently to inject code, then you could potentially cause a miscompile that invalidates the proof. One solution for that is to use memory-safe compilers but the only one I know of is Graal.

Discouraging the use of web application firewalls - https://news.ycombinator.com/item?id=38255004 - Nov 2023 (125 comments)