Looking at the capabilities of the default users created by the software after fresh install is difficult to wonder if it should be audited to ensure nothing hinky has occurred? Fuck me, if that's truly the case, we're all doomed. If the system modified anything, then those modifications should obviously be checked out to have done exactly and only what they were expected to have done. Installers typically have elevated privileges, and are known vectors for oopsies let alone maliciousness. Hell, Zoom left an elevated binary because it was simply easier for them to do things vs malicious. To have an "audit" not inspect these things is such an obvious error on the auditor's behalf.
Applications have default admin users. Nobody saw log4j for 15 years. Hindsight is a great thing to have.
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.
Take it from someone who works in the industry, this stuff is -hard-. I could go and be a developer with similar pay, think half as much, and have half as much responsibility. The industry is broken, and the subject matter is highly complex. Acting as if everyone is incompetent because nobody noticed a hardcoded Cred in a third party plug-in (until someone-did- notice it) alienates people from getting into the industry in the first place.
Security aren’t infallible, nor are developers, nor are you.
I'm saying the Dev that hardcoded a password is near incompetent. The fact nobody else working with that dev in code reviews found is near incompetent. I'm saying that you telling me as an auditor not checking the changes to the system after the software being audited is installed seems ridiculous to not be testing users etc as was claimed isn't normal.
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.
