"The advisory placed much of the blame on Versa customers who “failed to implement system hardening and firewall guidelines…leaving a management port exposed on the internet that provided the threat actors with initial access.”"
If ISPs are leaving management ports open on the Internet, it's going to take more than a vendor patch to protect them from cyber warfare.
In that story why was the replaying of HTTP requests so suspicious? They were cleartext requests sent over the internet, anyone could have seen the path.
Just because it's physically possible for someone to passively MITM a connection doesn't mean everyone and their dog is actually listening in on it. If they were, there'd be a booming industry of leaking celebrities' scandalous DNS requests. Instead, I'd suspect that actual actors with that capability wouldn't be burning it on small-time replay attacks.
Yeah but come on. Everytime someone says "There needs to be a regulation or a certification" forcing cyber hygiene this whole site rises up in arms clamoring that checklists mean nothing and prevent nothing.
This is what you get when there's no checklist enforced. I would like to see all those people pour into the conversation jumping up and down with glee that their plan worked.
The objection to Regulations, checklists, etc seems to stem from the idea that the Checklist will include 100 useless or worse items (405.i.18: Passwords MUST BE rotated by the user every 30 days) for every good one like "close the damn ports". In theory, such a thing will just slow a solid admin down.
I don't think this aligns with the reality of modern IT. Even with high competence and good intentions, it's an organizational problem and mistakes are easy.
There’s a strong argument that checklists are the opposite of what you want. In your example if I give you a list of ports to close, you might close those ports and leave all others open, and you would be “compliant” but still in danger.
You really need better defaults (“all ports start closed”) and a culture of strong justification for any changes from the known safe defaults.
This is of course at odds with convenience so it probably won’t happen.
My thought was something like UL certification on IT devices, the way they certify that products are electrically safe and won't start fires, they could certify at minimum that they don't have any open ports by default, are not delivered with default well-known or easily guessed passwords, are not running ancient versions of ssh or php or other software, are resistant to online attacks at least at a "script kiddie" level, etc.
The problem with that, however, is that vulnerabilites are constantly discovered, and what is safe today is not safe tomorrow. Electrical safety and fire resistance is much more permanent: if it's done right, it's likely to be safe for a long time.
We already have that. The Common Criteria (ISO 15408) has existed for literal decades at this point and is required for usage in government systems.
Vendors just find it too difficult to certify against attacks at the “script kiddie” level, so they lobbied the government to lower the standards so even the lowest rated systems, ones not even audited for security, are allowed for general usage in critical systems.
The large commercial vendors, such as Apple, Microsoft, or Amazon, have spent billions of dollars and literal decades trying to improve their security and have uniformly failed to certify that they can deploy any system that can protect against small commercial teams unlike actual high security vendors who can produce systems secure against even state actors.
It’s worse & an intractable problem. “Close the damn ports” may very well be one of those useless items for 1 team and relevant to another. So do you have team specific checklists or generic checklists that everyone must follow. If you have specific checklists, then you miss things that are relevant. And what happens when you make a change to how the system works & some item is no longer relevant while another becomes relevant? There’s no easy answers here I think with respect to checklists.
But you can, as an organization, choose to follow one and be "Secure by default", with exceptions e.g. "Open a port other than 443 to the Internet" being understood and risk managed.
It will slow down developers, for sure. But everything's a tradeoff.
I’m just saying that the objection of N:1 ratio of bad to good items on a checklist remains precisely because of the reasons I outlined. I have seen this repeatedly in design spec reviews to the point that people start skipping the checklist because it’s worthless boilerplate.
You can find hundreds of upvotes for checklists. The same sort of institutionally-decreed checklists. For every admin that lets compromised passwords linger there's one that can closes his port and vice-versa.
It's a cultural resentment of being forced to do the simple things. You dont honestly think a doctor needs to be told how to prep for surgery. But the doctor has and follows a checklist. You don't honestly think a pilot needs to be told how to prep for departure, but the pilot follows a checklist
Watching "modern IT" people demand special treatment because "modern IT" is just built different than modern flying or modern surgery is watching the height of arrogance.
> Watching "modern IT" people demand special treatment because "modern IT" is just built different than modern flying or modern surgery is watching the height of arrogance.
Not really. In > 99.99% of software projects, the risk of an error leading to people dying is lower than it is for a surgeon or a air traffic controller.
Additionally, software is an extremely broad tool, like mathematics, that can be applied to nearly any domain. Consequently, slowing down devs via regulation as you suggest will also slow both technological progress and economic growth. In a few circumstances, the risk may be enough to justify that cost, but it there’s high bar to clear.
If ISPs are leaving management ports open on the Internet, it's going to take more than a vendor patch to protect them from cyber warfare.