|
|
|
|
|
|
by rzazueta
939 days ago
|
|
|
If the org has a software development team, there's really no reason not to roll your own. As stated previously, this is a pretty well solved and well documented problem. A lot of development teams outsource this under the idea that authx is not their core competency, but I'd argue protecting customer data ought to be among every development org's core competency, otherwise they;re asking for trouble. If you're talking about orgs that don't have a dev team and buy everything off the shelf / through SaaS... well, this is unfortunately part of the risk those orgs run. If you're manufacturing and shipping widgets in boxes, and your box supplier starts using cheaper materials that don't hold up to shipping, the only option is to switch box providers. Same here - if you're org relies on an IAM tool to allow employees to log into SaaS or other hosted software platforms and the IAM leaks data, the only real options are to switch providers or work with the existing provider to fix the damage. |
|
|
Why not write your own OS? Then you can control the vulns!
Why not design your own hardware? You can secure the hardware comms channels better.
Why not invent your own coding language? You can ensure it's written with zero vulns.
Why not invent a new base-30 numbering system? With out extra efforts, they can't even read your excel spreadsheets!
Your solution works in a select few companies that have monster dev farms, but everyone else cannot implement this and it's silly to tout it as a solution.
There are zero perfect solutions.
The way we do this in the real world, is patch, read up on vulns that might affect us, monitor, control access, and audit.
It's still not perfect, since nothing is, but in 30+ years of managing Healthcare IT and being senior technical, I've had exactly 1 breach and she did it with pencil and paper, at an HIS workstation, who's job is to look at many medical records, daily.
Your Mileage Will Vary.