Meanwhile, the router that serves my office is from a company that's had fewer than nine security problems in the past ten years. Two, I think, but I confess I don't really keep count (ditto the nine above). The precise number doesn't matter, because
1. If you want to be cynic you can point out that 9>0 and 2>0 and really they all suck.
2. And if you don't want to be cynic, then Cisco's recent record is in a league of its own. Steals the show. Makes other people's CVE count look like rounding errors.
Also the 9th they have fixed.
> Not ninth security problem total, ninth backdoor. The ninth security problem Cisco shipped intentionally.
How can you be sure it was intentional?
> Meanwhile, the router that serves my office is from a company that's had fewer than nine security problems in the past ten years.
How can you be sure? Did you audit all the source code yourself? Did you compile the source code yourself and are you running only binaries you compiled? Are you sure you can trust the compiler you used?
Or, are you assuming that, because there isn't a CVE, there isn't a vulnerability or security problem?
Fewer CVEs doesn't necessarily mean more secure, it may just mean less validation/testing etc.
But sure, it could mean more secure, it's just not a guarantee.
I've worked for a company that built OS images for distribution to customers. Putting my SSH key in development image builds would have been convenient, but there was too much of a risk of exactly this problem; instead we just made it easy enough to download an SSH key on a development build (and start up an sshd) once you've booted it and have physical access to a terminal.
Also, a practical concern with disclosed vulnerabilities is that non-nation-state attackers (which are most of the attackers most people care about) are very unlikely to find and exploit a vulnerability that neither has a public CVE issued now nor will have one issued for years. So even if the alternative vendor has difficult-to-discover vulnerabilities, there is, in a very real sense, reduced exposure from those vulnerabilities compared to things that are disclosed and fixed. And especially if Cisco's disclosed-and-fixed vulnerabilities originate from outside vulnerability reports, there's a definite correlation between whether a vulnerability can be found by someone who would report it and whether a vulnerability can be found by someone who would exploit it.
Backdoors are unusual: They happen because someone writes code of the form addAccount("s3kr3e", "s3kr3t"), and that's code that's written. You can typo and accidentally omit a bounds check, but you can't typo and accidentally end up with a valid SSH key pair and code that installs it.
It's possible to ship that SSH key pair and the code to customers that as a bug, e.g. if someone writes that code on purpose, intending to add and deploy s3kr3t/s3kr3t but not intending to ever have that code on the branch that's deployed to regular customers, and then someone else mismerged. In that case serving it to customer X is due to a bug, it should only have gone to customer Y or test environment Z. What I'm saying is that shipping those backdoors at all must have been intentional.
(Personally I think shipping backdoors to test environments is fine. Including test environments at customers. Risky.)
We are moving offices, and it's time to change equipment, Been reading about but still haven't gotten a good list.
The only thing i found is great micro tick for wifi routing/AP's
All of those will give you hardware that does the job and stays up, and provide uncomplicated upgrades for many years.
