i dunno maybe i'm in the wrong field but at least i would check that out.
But when that line of work started putting food on the table, it really softened the ground. “Cybersecurity” is something people understand better than “infosec,” and a part of being a professional is being able to communicate about your work in relatable terms.
So I stopped worrying about those people. I came to discover few of them knew their way around my field, so I stopped being insulted by them. They didn’t know what they were talking about.
It also would affect business relationships which is something every employment contract I’ve ever signed has stated is something which is a violation of my employment terms.
So, to pile on a little: yes, the parent is right in a lot of cases, there are exceptions, but of 12 audits maybe 10 were essentially Nessus version checks. This was needed mostly for rubber stamping.
Better ways to say the same thing without undermining people's trust in the whole idea: There are lots of scammy security audit companies, Confluence should make sure to engage a good quality ones. Companies should invest in serious pen tests rather than just org compliance for security. Here are companies that actually did a good job...
Unless the goal is to bury the whole idea under a list of issues with bad actors and make sure nobody knows there are alternatives?
………..
This has nothing to do with elevated binaries or anything else.
To be clear, security is assurance. It’s not just security who screwed up here, it’s also the devs that shipped it, the testers for not raising it, and product managers for not ensuring better quality assurance didn’t occur.
Yup. And after install, they should be tested. Default non-admin users should also be tested for the basic thing to ensure they are actually restricted and can't do admin things.
>Nobody saw log4j for 15 years. Hindsight is a great thing to have.
You are moving goalposts here. Nobody mentioned log4j issues. The issues being discussed here do not require hindsight.
Confluence left a hardcoded password. At the point a dev is harcoding an f'ing PASSWORD, alarms should be going off with flashing lights and everything. If an auditor isn't searching the codebase for something simple like 'password = ' to see a hardcoded string, then that's a weak audit. The fact no internal code review didn't catch this is also not a good sign.
100% agree no single person can imagine every single scenario that would potentially cause problems down the road. However, when new things pop up, they should be added to a list of things to check for not an immediate throwing of hands in the air with a "we don't do that kind of thing". Instead, admitting it was checked for because it was such an out of consideration thing, but then saying "we'll keep that in mind for future testing" would have been a much better thing response than a bunch of whataboutisms.
Security aren’t infallible, nor are developers, nor are you.
Yes, we're all error prone. Some mistakes are innocent and triggered by multiple layers of things aligning, some mistakes are from not enough experience, some are malicious, some are just other things. Hard coding a password is damn near unforgivable though.
My faith in the former is strong, the latter category worries me.
But you're basically right. And now there seems to be a meme going around that it's elitist and inappropriate to expect people to have any technical understanding at all before they start dictating technical decisions around security, and all you need is a willingness to learn the alphabet soup of requirements and mindlessly apply the checklists.