51–60 of 83 posts
Earlier quoted context omitted.
can it even be considered a firewall if it's running in an "audit only mode"?
(Corporate IT sec answer): it says "firewall" in the name, so yes.
Every corporation over a certain size has a rule that everything needs a firewall in front of it… even if the something is a cloud service that only listens on port 443.
Other than the myriad of problems with passwords that NIST has killed in competent circles, what are some other "useless controls"?
Password resets are definitely one, and I still have to tell prospects and customers that I can't both comply with NIST 800-63 and periodically rotate my passwords, every single day. Other ones I often counter include other aggressive login requirements, WAFs, database isolation, weird single tenancy or multitenancy asks, or for anti-virus to be in places that they don't need to be.
I just read the book The Phoenix Project. It's over a decade old so some of the principles are obvious/quaint at this point, or perhaps not quite as applicable. That said, one of the things that caught me off guard is the dressing down of the head of security by a member of the board. More or less, they were told what they did was clog the flow of useful work. The message conveyed is similar to this post.
I think the book is still very applicable, and every security practitioner needs to be hit over the head with it (or at least The DevOps Handbook or Accelerate). Security generally is decades behind engineering operations, even though security is basically just a more paranoid lens for doing engineering ops; the ideas from Phoenix are still depressingly revolutionary in my field.
I just read the book The Phoenix Project. It's over a decade old so some of the principles are obvious/quaint at this point, or perhaps not quite as applicable. That said, one of the things that caught me off guard is the dressing down of the head of security by a member of the board. More or less, they were told what they did was clog the flow of useful work. The message conveyed is similar to this post.
> More or less, they were told what they did was clog the flow of useful work. That sounds like a very valid complaint, too rarely heard these days. People seem to forget that security always comes at a cost, so security decisions are always trade-offs. The only perfectly secure system is the one that does absolutely nothing at all. Does forcing everyone's machine to run real-time scans on all file I/O improves our s…
Other than the myriad of problems with passwords that NIST has killed in competent circles, what are some other "useless controls"?
>that NIST has killed in competent circles Just because this is my favorite soapbox - anyone that has to deal with passwords should go read NIST SP800-63B: https://pages.nist.gov/800-63-3/sp800-63b.html I was kind of shocked by just how gosh-darned reasonable it is when it came out a couple of years ago. It's my absolute favorite thing to cite during audits. "Are you requiring password resets every 90 days?" "No. We…
What? React is not "Cross-site scripting safe"
Many security controls do require more than a 2-3 sentence explanation. Trying to condense your response in such a way strips out any sort of nuance such as examples of how react can be susceptible to XSS. Security is a subset of engineering and security decisions often require a trade off. React does protect against some classes of attacks, but also exposes applications to new ones.
Earlier quoted context omitted.
You don't need to understand the logs at the time you gather them for this, you just need to keep them long enough to cover the breach, and to be able to understand them after the fact. Hardly seems like an obvious waste to me, and well worth $500/mo.
> you just need to keep them long enough to cover the breach, and to be able to understand them after the fact And avoid leaking customer information/passwords/etc. through them until then, which is the hard part.
Check the box for WAF but adds a new risk.
The vast majority of the security "industry" is about useless compliance, rather than actual security. The chimps have put their fears into large enterprise compliance documents. This teaches the junior security people at enterprise companies that these useless fears are necessary, and they pass them along to their friends. Why? Not just because of chimps and fear, but also $$. There is a ton of money to be made off…
* You get a cool industry certification that you can put on your website to justify the vague "we take your security seriously" platitudes we spew.
* It lets you stop putting money and effort into security once you've renewed your certs this year.
* You don't need to hire a dedicated security person, any sysadmin can check boxes.
* You can say you followed industry best practices and "did all you could" when you get breached.
It's the answer to "how do we not care about security?" across an entire industry that stands to make billions from said lack of care. In a depressing way, the company with useless performative security certs will fare better after a breach then the one without them but that actually tried.
My less cynical take about this is that if you need to actually care about security because you'll be up against sophisticated targeted attacks then you probably already know that. For everyone else there's checkboxes to stop companies from getting owned by drive-by attacks.