Slashdot Mirror
Ask Slashdot: Share Your Security Review Tales
New submitter TreZ writes: If you write software, you are most likely subject to a "security review" at some point. A large portion of this is common sense like don't put plain text credentials into github, don't write your own encryption algorithms, etc. Once you get past that there is a "subjective" nature to these reviews.
What is the worst "you can't do" or "you must do" that you've been subjected to in a security review? A fictitious example would be: you must authenticate all clients with a client certificate, plus basic auth, plus MFA token. Tell your story here, omitting incriminating details.
What is the worst "you can't do" or "you must do" that you've been subjected to in a security review? A fictitious example would be: you must authenticate all clients with a client certificate, plus basic auth, plus MFA token. Tell your story here, omitting incriminating details.
You were hired for a lower paying position because they felt you weren't qualified enough for the position you applied and then had you doing it anyway for less pay because your title was still something else.
This is standard practice.
I have been a developer since about 1990 and I have been occasionally re-purposed to perform security reviews
The first time was in 2000, we were a data center that was part of a fairly new fiber company.
We were in a partnership with a large document management company and some open source organization.
The website that we were hosting kept crashing and the PM responsible for it had lost the admin password.
It ran on Oracle and I was able to use some default passwords and os level functionality in Oracle to grep the file system and identify the system passwords.
Unsurprisingly, I found that they were using commonly known passwords that were present throughout their training materials
When I asked if they could change the default passwords to new values, and rotate them regularly, the response was "No, we think that will break everything"
This resulted in two things, I because the Unix security guru, and I got them kicked out of our datacenter.
Similarly, one day our SAN admin noticed that DVD images were being stored on our SAN. We traced it back to another start-up that had been using TELNET to log into their box as root. Apparently this traffic had been sniffed out and our systems had been compromised. This resulted in a clean-room rebuild of all active systems and me being tasked with writing security policies to publish to our customers, follow them and be welcome, don't follow them and buh-bye...
You may notice that this is all being done in a completely reactive manner since at that time, apparently, nobody in the fucking planet had a clue about how to build and admin a secure system.
Since that time I have fought the "make a system where you can change the default passwords", "Keep your systems patched up the currently available level", "why the fuck are you passing strings to your database without scrubbing them", and "sure, that is what you think your firewall is doing, but it is not really doing that" battles over and over and over.
They say that security starts at the code level, and you can really fuck yourself over by taking a poor approach, but most security problems are just plain piss-poor admin skills. IMHO