Kate Temkin
periodic reminder for infosec folks: stop deciding things are done badly or "insecure" outside of the context of a threat model
it's disingenuous and irresponsibly ignores that security and cryptography are fundamentally about balancing risk tolerance and risk abatement
Eleanor Saitta
@ktemkin
I think there are two different categories here. System design needs to be evaluated in the context of a threat model, yes (and a lot of what gets called a threat model is at best a colloquial approximation of actual thinking), but basic vulnerabilities, whether that means parser and state machine issues, memory issues, or issues of incorrect implementation of a chosen set cryptographic primitives, all qualify as "done badly" in most cases and insecure in the majority of foreseeable threat models if they're in reachable code.
"Has an open port connected to the internet" implies a minimum set of things that must be accounted for in a threat model, as is "supports messaging between users".
Eleanor Saitta
@ktemkin
We talk about these things because we have spent literally the last twenty years looking at threat models and at the failure of overworked dev teams to build good code with bad tools. It will be an amazing victory for the community when developers have to actually design the bugs that fuck them over. And no, the correct way to fix these issues has never been to write bad code and then try to audit it, obviously.
Yes, in the context of each individual program, the threat model wins. In the context of the entire industry, this is not how progress is made.
Kate Temkin
@dymaxion threat models still apply to all of these things; they're literally what you use to determine where you spend the limited time you can spend on security (whether that's training coders, auditing code, choosing what to harden, etc etc)
folks can lecture for days about how parser bugs creating weird machines is a serious threat, but if the parser is parsing some saved configuration flash on my digital stylus, chances are the worst that could come of any attack is a bricked stylus.
if you've spent your limited time and energy making sure that's ultra-audited because it's a parser, you're taking time away from things like "realizing that the auth token included in the GET requests for the firmware updater actually also has permissions to fetch and overwrite other products' files"
Rich Felker
@dymaxion @ktemkin "Ambient attacks against open ports exposed to network" needs to be considered an implicit part of any threat model for software/devices designed to be connected to a network. It's not optional.
Kate Temkin
(this message brought to you by yet another infosec person writing a huge 'teardown' of soneone's use of cryptography... without bothering to understand that a cryptosystem that protects against every possible attack---no matter how construed---would have such bad ergonomics as to be useless)
Kate Temkin
@dymaxion infosec folks who then spend their time loudly, publicly calling products crap because of they've identified parser bugs -- without understanding what makes them insequential -- actually can shift manufacturer priorities, making them more likely to spend their time on the stuff that's visible rather than the stuff that's actually applicable to their threat model
Eleanor Saitta
@ktemkin
One of the things I hope we can strongly agree on is that the place where we should be asking a lot more is at the library and language level. I agree it's implausible that small teams will fix annoying and subtle bugs and also do the basic security design work they're already not doing. However, it seems equally unlikely that people are going to stop doing dumb shit like connect things to the internet that really shouldn't be. Teaching the entire world how systems work to a level that allows them to have good intuition about what's a safe action is as hard as getting all the small dev teams to do the work. And harassing either users or devs about things outside of their scope of effective control of dumb and mean.
So that means we need language, framework, and library issues fixed at those levels, and then we need shaping incentives like liability to force migrations and rewrites, once we have meaningful solutions. When we get to that point, yes, a lot of small teams will need to end of life products or accept that they're going to need to write a lot less code — but at least they won't be playing whack-a-mole with problems further up stack and above their pay grade.
@dalias
Kate Temkin
@dalias @dymaxion I don't generally subscribe to statements that ignore nuance.
While I accept that there's generally some responsibility to prevent machiens from themselves turning into threat vectors (e.g. it's not great to have your iot device be easily made part of a botnet), I am also not going to suggest there's an oversized onus on the authors of e.g. a Thread flashlight to make sure their little uC that's too slow to render its own confiugration UI and which could last maybe five minutes as a slow-as-hell active threat before its battery ran out is protected from the other devices on the theoretically-bridgable Thread network
especially when the time is better spent e.g. understanding that the best solution to most problems that could include many devices is to improve the UI so people stop using insecure defaults
this is why threat modeling is important and nothing is just an implicit "responsibility' with its priority fixed to '1'
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.