sed quis custodiet ipsos custodes?
But who shall guard the guards themselves?
Western cybersecurity agencies have published a list of 30 of the most exploited vulnerabilities abused by hostile foreign states in 2020, urging infosec bods to ensure their networks and deployments are fully patched against them. Number one on the US, UK, and Australia's jointly published [PDF] list was the well-known Citrix …
Looking this dozen up on the CVE, I find:
four failures to sanitize properly;
two failures to parse properly;
one failure to validate properly;
one poor encryption implementation;
one instance of development code left in release;
one instance of open access to script components;
one instance of poor memory management;
one instance of uncontrolled file write.
All these are really quite basic errors that should at least shown up under pre-release testing, and it's interesting (and disturbing) that over half of them are failures to ensure input is valid and legal.
Good work - and maybe not surprising. Releasing good code is expensive. I guess that an analogy is safety critical development (SIL, SW01, DO-178, etc). These standards don't just focus on development, coding and testing, but on the company environment and processes that surround and support them from design concepts to in-service support. It makes SW development in these environments expensive, a bit less fun sometimes, and it makes it much harder for a director to shout "just fucking release it or we'll miss this quarter's numbers".
I don't think we'll ever see security equivalents of these safety standards, partly because of the expense but mainly because of today's expected rapid turnover of product and introduction of new features.
>So basically programmer laziness
Maybe, but there could be a lot of other explanations. The most likely based on my own experience is that there's just too many bases to cover and too few people to cover them. Management tends to underestimate both the scope and depth of problems, both tangible and likely, because it impacts schedules. They're particularly sensitive about programmers who are not actively working on a project they can book hours against even though those programmers may be doing what could be described as essential QA functions. (In my experience QA departments are very good at finding user interface bugs and other directly operational problems, they're also good at running canned test programs and certification scripts. What they're not very good at is really subtle problems because these actions have to deliberately look for trouble, they're more of a developer role than a tester.)
Anyway, its a bit unfair to just describe programmers as 'lazy'. Its a typical 'never done complex development in a team environment' statement, the sort of thing you get from disconnected managers.
As defined by Five Eyes infosec agencies, obviously. I'm guessing that is basically the Five Eyes infosec agencies themselves, but who knows? And is there a third category: neutrals? Maybe not, anyone who spies and doesn't share with Five Eyes infosec agencies would go straight into hostile.
I'm also guessing my downvotes are from Five Eyes infosec agencies, hi there, you know where I live.
Biting the hand that feeds IT © 1998–2021