Earlier quoted context omitted.
If bad actors learn about the fail-close, they can conceivably cause you more harm.
This is a losing money vs. losing freedom situation.
Maybe. But for a company everything is fungible.
Turn Dependabot off
191–195 of 195 posts
Re: Turn Dependabot off
#192Earlier quoted context omitted.
Honestly, that whole "free as in X" problem to me seems like an English only problem. As an ESL I perceive "free" to be the adjective to "freedom" by default and the other meaning to be a contraction of "free of charge".
Which is not a minor or trivial language, GPL was written in English, by an American developer, while working at an American company, etc... Same with GNU and FSF
Not it isn't, but words derive their meaning not necessarily only from a single language.
Re: Turn Dependabot off
#193Earlier quoted context omitted.
> If the system is configured to "fail open", and it's something validating access (say anti-fraud), The problem here isn't the DoS, it's the fail open design.
If the majority of your customers are good, failing closed will cost more than the fraud during the anti-fraud system's downtime.
Okay, then the “vulnerability” is de facto simply transitioning the system to an acceptable state.
Re: Turn Dependabot off
#194Earlier quoted context omitted.
TBH I Think that DoS needs to stop being considered a vulnerability. It's an availability concern, and availability, despite being a part of CIA, is really more of a principle for security rather than the domain of security. In practice, availability is far better categorized as an operational or engineering concern than a security concern and it does far, far more harm to categorize DoS as a security conern than it…
If I can cause a server to not serve requests to anyone else in the world by sending a well crafted set of bytes, that’s absolutely a vulnerability because it can completely disable critical systems. If availability isn’t part of CIA then a literal brick fulfills the requirements of security and the entire practice of secure systems is pointless.
> If I can cause a server to not serve requests to anyone else in the world by sending a well crafted set of bytes, that’s absolutely a vulnerability because it can completely disable critical systems.
Well obviously I reject that, right? That's sort of my point.
> If availability isn’t part of CIA then a literal brick fulfills the requirements of security and the entire practice of secure systems is pointless.
That doesn't follow at all. If I say "availability is an operational concern and not a security concern" it does not follow then that "remote code execution is not a security concern" whatsoever.
Re: Turn Dependabot off
#195Earlier quoted context omitted.
If I can cause a server to not serve requests to anyone else in the world by sending a well crafted set of bytes, that’s absolutely a vulnerability because it can completely disable critical systems. If availability isn’t part of CIA then a literal brick fulfills the requirements of security and the entire practice of secure systems is pointless.
> If I can cause a server to not serve requests to anyone else in the world by sending a well crafted set of bytes, that’s absolutely a vulnerability because it can completely disable critical systems. Well obviously I reject that, right? That's sort of my point. > If availability isn’t part of CIA then a literal brick fulfills the requirements of security and the entire practice of secure systems is pointless. That…
No, the answer to every security concern can be “don’t attach it to a network” in your view. That’s why it’s so incredibly stupid to not have availability in the framework.