The correct answer is that THIS IS FREAKIN' KERCKHOFF'S PRINCIPLE FROM 1880!!!!!!! Seriously, at some point we have to point out YOUR CONCERN WAS ADDRESSED OVER 100 YEARS AGO!!!!
Yes, yes, we can't apply this principle has a clichéd response to every question (as some people do). But at the same time, we can apply it where it's clearly appropriate, such as in this case.
The naive believe we need to hide the details of how things work, in the name of security, so that the attacker doesn't know the details.
Kerckhoff's principle is that the attacker can figure out these details anyway, that you are doing much less than you think to hinder them.
What you are doing instead is hiding the details from your friends, who would otherwise be able to point out of the flaws in a system.
SBOM has many problems, but the one problem is doesn't have is the benefits of transparency. Such transparency so that customers (in particular) and the public (in general) know the components of a system is a net improvement in security -- according to over 100 years experience.
Even if you reject transparency-for-cybersecurity, it's the same thing as transparency-for-government. It's why we have FOIA, accountability for spending, election finance laws, and so on: security comes from transparency not secrecy.
The fact that transparency helps defenders more than attackers has been the repeated observation in cybersecurity since the 1880s. I shouldn't have to yet again defend this principle in 2021.
Now I hate clichés. Maybe you have a more sophisticated argument that I'm strawmanning into this argument. But so far, in regards to SBOMs, with criticism from those like Oracle, I haven't found the more sophisticated argument.
Oracle is a shittastic company. They reject transparency because they don't want their competitors to know all the components of their system. I suspect they reject transparency to hide their violations of the GPL.
These are all good reasons to reject transparency. Cybersecurity isn't some moral imperative that overwhelms other concerns, such as protection of trade secrets. But people don't like to argue thusly, so they pretend they are arguing about something else.
Thus, the argument "transparency leads to insecurity" isn't even serious to begin with, they are really meaning "transparency reveals our trade secrets".
Note that I'm happy for closed-source software companies like Oracle to protect trade secrets. I'm not criticizing them for that. I'm criticizing them for the dishonest and unprincipled "transparency is bad for security" argument. Bad argument is bad.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
So I'm reading the CFAA decision. I want to point out yet again that the "mens rea" requirement in the CFAA is bullshit. It doesn't mean the perp knew they were unauthorized, it means a reasonable person in the perp's place would've known they were unauthorized.
I can appreciate that in most crimes, this is the reasonable approach.
It's just that in computer crimes, it's not. People have wildly different understands how computers work, and thus, different understands about what's authorized.
Most people are unintimidated by the URL bar in the browser and have never edited the URL in their lives. Thus, reasonable people assume that if you couldn't have accessed a resource without editing the URL, then it was unauthorized.
I'm somebody who actually likes the Federalist Society. How can it not vigorously defend the free speech rights of this student for what's obviously satire????? What part of "free speech" are people not understanding any more?
Ransomware is an 'existential threat' to business. What's your plan to respond to it? Wrong answers include "we are prepared" and "doing better at cybersecurity basics".
I mention this because I read a lot of op-eds by infosec types that claim that ransomware demonstrates the need to for better cybersecurity. I disagree. I think we need to actually pay attention to the specifics how ransomware attacks work, and address those specifics.
Anybody says "we need to take it seriously", about any topic. Here's my take on the Israel-Palestinian crisis: "The recent rocket attacks by Hamas and Israel's response demonstrate how the United States needs to take this conflict more seriously". See how it works?
There are three possibilities: 1. they hacked Constant Contact and can use any account there 2. they hacked USAID and can use any service for which USAID has an account 3. they hacked just the USAID account at Constant Contact (e.g. from "credential stuffing")
Possibility #1 would be a supply-chain attack like Solar Winds.
Possibility #2 would be an attack against the US government, like against OPM
Possibility #3 is just a common thing teenager hackers do and is relatively silly
As far as I can tell from the publicly available information, the SVR hackers did not hack into either the USAID organization nor into Constant Contact "systems" as the NYTimes claims in this story.
The hackers appear to have used the USAID.gov's account at Constant Contact, a mass emailing firm. This implies neither a hack of USAID nor of Constant Contact -- only a hack of the password used by somebody at USAID to log into Constant Contact.
Password reuse is a chronic problem. If "ashainfo.gov" used the same password for Constant Contact as they used for "canva.com", then we see how this "hack" happened. It's an extremely common, easy attack, and does not represent an "escalation".
You know how they blew up the second Death Star exploiting the same failure as the first? It's because the Empire reacted like this to the first one that blue up: "Let's ignore that vent and apply bureaucracy to the problem".
Every ransomware I've seen leverages the fact that it's easy to get "domain admin" then own the entire enterprise. Centralizing everything with "Active Directory" is the ventilation shaft of modern Death Stars.
If you look at case studies that look step-by-step how ransomware hackers worked, such as spreading laterally with Mimikatz, then compare these to the cybersecurity guidelines for pipeline operators, you see they aren't related to each other. tsa.gov/sites/default/…