Read on Twitter
(thread)
Preface: I'm not a security expert, but always try to find best practises for technologies that I'm working with.
Perhaps quick start guides or default settings for technologies shouldn't focus on "getting started in minutes".
Preface: I'm not a security expert, but always try to find best practises for technologies that I'm working with.
Perhaps quick start guides or default settings for technologies shouldn't focus on "getting started in minutes".
There are a LOT of technologies that we rely on for our work, and the majority of them have exploits for "misconfigured" or default states. And the majority of those default states are not production ready.
Perhaps these systems could detect a default or a "quick start" config, and annoy the dev team into changing the config.
Or perhaps they could detect when they are in running production, and intentionally run badly because they are in production with a bad config.
Or perhaps they could detect when they are in running production, and intentionally run badly because they are in production with a bad config.
Of course, the real answer to this is to allow tech workers to set up the software and tech that they use correctly. But there's often pushback against that, as its not "revenue generating work."
There's an argument for fighting against that, too. And we should always do that where possible - we're the experts, after all.
Or perhaps we should think about "revenue protection work" or "exploit removal work" rather than "revenue generating work."
(/thread)
Or perhaps we should think about "revenue protection work" or "exploit removal work" rather than "revenue generating work."
(/thread)
