Security and Proprietary Software
-
Security done right – infosec wins of 2022
As 2022 draws to a close, The Daily Swig is revisiting some of the year’s most notable web security wins and egregious infosec fails.
Yesterday we showcased the year’s biggest fails – the security disasters, industry calamities, and the emergence of vulnerabilities so stupid they’ll make your eyes roll.
Today, we’re celebrating the times that organizations, governments, and the infosec community have shown laudable skill, judgement, and commitment to better securing the cyber sphere in 2022.
-
The perverse incentive of vulnerability counting - Open Source Security
It seems like every few years the topic of counting vulnerabilities in products shows up. Last time the focus seemed to be around vulnerabilities in Linux distributions, which made distroless and very small container images popular. Today it seems to be around the vulnerabilities in open source dependencies. The general idea is you want to have as few vulnerabilities in the open source you’re using, so logically zero is the goal.
However, trying to get to zero vulnerabilities in your products, projects, and infrastructure is a perverse incentive. It’s easy to imagine zero as the end state, but you end up with the cobra effect. A goal of zero vulnerabilities will result in zero vulnerabilities, but not in the way you want. And really zero isn’t what you want, what you want is process that reduces your risk. If all you focus on is vulnerability counting, there’s a very good chance you would lower your vulnerability count and accidentally increase risk elsewhere.
[...]
Why is zero vulnerabilities impossible? It doesn’t seem like it should be all that hard to fix all the vulnerabilities. Just run super small containers, use only the dependencies you need, upgrade everything quickly, and DONE!
This is probably true when you’re a small team (or maybe giving a conference keynote), but if you’ve ever been part of a group managing infrastructure more than a few years old, it’s rarely as easy as running the minimum and upgrading six times a day. You’re on the 12th generation of developers. Nobody remembers why you can’t shut down that machine in us-east-1, but if you do everything breaks. There are dependencies that you can’t find the source for anymore. The tests broke a week ago and there’s no time to fix it because everyone is off on Christmas break.
If you tell people like this they need zero vulnerabilities, they will find a way to make the scanner report zero. Upgrading everything quickly won’t be how it reports zero, it will be by doing things to hide vulnerabilities. This comes back to the idea of increasing risk elsewhere. While hiding things gives the impression of reducing risk, we’ve actually increased the overall risk by a lot.
-
A Racket program to decrypt files encrypted with Synology Cloudsync - Nikhil's blog [Ed: Well, proprietary decryption is not trustworthy. Windows and macOS are controlled by companies that cooperate with the NSA and actively facilitate remote access by the NSA.]
The decryption software is not open source, and is a Windows and macOS-only GUI app. My version can run on any platform
-
Research Unix V2 already had a lot of what we think of as 'Unix'
When I looked into how far back Unix's special way of marking login shells goes, I wound up looking at the V2 source of login.s, which is a .s file instead of a .c file because C (the language) was barely starting to be a thing in mid-1972. One of the things that struck me when I looked at the V2 login.s was how much of what we consider standard Unix features were already there in some form in V2.