Trust no one: why we can't trust most stats about the cybersecurity industry
ventureinsecurity.net
ventureinsecurity.net
This problem, though, is multiple-fold. The author gave a non technical perspective, but I'd like to add some points that he missed in the article.
1. Companies have no legal incentives to share they've been breached. Quite the opposite, it's better from both a financial and a legal standpoint to keep it a secret. This has to change, and legislative bodies failed to do so.
2. Vendors don't have legal incentives either. If Siemens is breached, nobody knows about it. And that is very dangerous, considering their role in critical infrastructure. CERT tries to change this, but guess what, Siemens doesn't disclose shit there.
3. Software vendors don't even maintain their software and they get away with it. Look at Sophos, Fortinet and others. Multiple RCEs over the years due to them writing HTTP parsers in C++ without any quality improvements. Code is written so sloppy that even SQLi works, and apparently never improved upon and neither refactored.
4. All measurements are hypothetical. Especially risk management is completely made up. They always cheat themselves by claiming "this is not feasible", well, even though the RCEs are shared as PoCs on Telegram. Being blind to better sources of information actually helps them cheat their own metrics, and lazy teams are, well, lazy. This somehow crosses over with cyber intelligence now, but in general all ratings of CVEs are bogus and the only ones you can trust are Arch Linux and Alpine. Debian always closes their hardforked version freezed but affected packages as "won't fix/not affected", and then it turns out they get hacked, too. Happened a lot of times. Lots of distros have OVAL data available, which makes this at least discoverable if you write your own software (or use ours :) )
5. EDR software and inventory software are as disconnected from each other as possible, which is a huge mistake. If you ask a blueteam about how many devices are in their network, you will be baffled by their answers.
Source: Am building an EDR software for POSIX systems from scratch, that is able to analyze malware on both a network level and an in-memory disassembler level (written in go and ebpf) and tries to change the game mechanics with automated communication between EDR agents.
The CIO clicked on a p0rn site?
Lots of companies did it the same way. SAP, Salesforce, Fortinet, Sophos, heck, even Solarwinds RCE was disputed - AFTER the whitehouse made a public statement about it.
I'd argue that NIS2 doesn't enforce much, because the "reasonably modern" lingo is used everywhere, which is a legal grey area that lazy lobbyists inserted for a good reason.
Legally speaking, base64 is a reasonably modern encryption, which says something about this, and the lack of technical correctness in the whole sector.
TISAX requires 24 hours response times, and the response is "We have received it" because it doesn't say that companies have to disclose or report any incident. Neither any mandatory time frames for bugfixes.
Same for all ISO norms, you can fulfill ISO 27001 et al with a single part time student job, which has 20+ role descriptions. Will the student get the job done? Probably not, but it's still passing the audit because auditors don't control the outcome, only the management policies.
We need to rethink how audits are done, because systematically paying auditors for implied successful audits is what got us here.
There's no problem in “cybersecurity”. The problem resides in the computers connected at either end, As in they can't differentiate between OPEN and RUN and can be hacked by opening an email attachment or clicking on a malicious URL.