7 battles #infosec has lost but we keep wasting efforts on trying to fight again and again nonetheless:
1) Users will always click on links in emails.
Stop trying to teach them to distinguish "bad" and "good" links. Instead, focus on ensuring their computer cannot be compromised by visiting a website and phished credentials are time-limited or otherwise useless to the attacker.
Stop trying to teach them to distinguish "bad" and "good" links. Instead, focus on ensuring their computer cannot be compromised by visiting a website and phished credentials are time-limited or otherwise useless to the attacker.
2) Users will pick bad passwords that they then reuse.
You can get _some_ users to use a password manager, but you can't enforce good passwords and practices. The only real solution is multi-factor auth, preferably via FIDO U2F and/or biometrics.
You can get _some_ users to use a password manager, but you can't enforce good passwords and practices. The only real solution is multi-factor auth, preferably via FIDO U2F and/or biometrics.
3) Developers will put secrets into code repositories.
Providing libraries to hook into your key management service is good, but the only solution is to implement identity-based, short-lived, automatically procured access credentials instead of static tokens.
Providing libraries to hook into your key management service is good, but the only solution is to implement identity-based, short-lived, automatically procured access credentials instead of static tokens.
4) The certificate ecosystem is a mess, and a rogue or compromised CA can issue fraudulent certs for your site.
There is no prevention, only mitigation and detection. The cost for this increases proportionally to how likely you are to be targeted here.
There is no prevention, only mitigation and detection. The cost for this increases proportionally to how likely you are to be targeted here.
5) Engineers will (build systems that) pull random dependencies from the internet.
Accept it, but try to at least limit the number of places on your network from where they are pulling them in, so you can add _some_ monitoring, alerting, and vuln checking at the choke point.
Accept it, but try to at least limit the number of places on your network from where they are pulling them in, so you can add _some_ monitoring, alerting, and vuln checking at the choke point.
6) Application owners assign trust to traffic from "internal" networks.
This is wny you need multiple levels: layer 7 auth and layer 3 automated, identity-based microsegmentation.
This is wny you need multiple levels: layer 7 auth and layer 3 automated, identity-based microsegmentation.
7) You can't manually update/patch all your software after a vulnerability becomes public.
That's chasing your own tail, mostly futile busy work. It seems important (and makes you seem important!), but perhaps instead aim for regular, automated, unattended software updates.
That's chasing your own tail, mostly futile busy work. It seems important (and makes you seem important!), but perhaps instead aim for regular, automated, unattended software updates.
Bonus: The DNS remains untrusted.
Even DoH and DoT cannot address that. DNSSEC is not going to come and save us. Somehow even #infosec isn't really fighting this. #ItIsWhatItIs
Even DoH and DoT cannot address that. DNSSEC is not going to come and save us. Somehow even #infosec isn't really fighting this. #ItIsWhatItIs
Final addendum: Yes, some of these can be fought and addressed by a very small number of very large organizations or controlled for very specific environments. I just don't think they can be universally solved.
