|
In my experience, a lot of corporate entities have bad rules like "30 days to review patches before they go live", or "no patches not reviewed by team X" that slow down changes. These sorts of caveats are both hard to change, and even harder to circumvent, because big companies make change difficult as they usually have more to lose than to gain. If you look at the article, it matches this idea: > ... Mr. Smith referred to an “individual” in Equifax’s technology department who had failed to heed security warnings and did not ensure the implementation of software fixes that would have prevented the breach. I doubt one individual is responsible for every patch in the organisation, and I reckon that Equifax likely has many individuals each responsible for different systems, all of whom have to deal with a central security department before they can, well, patch their system. I further bet the internal politics are off the chart, and the security team is a "no, you can't do that" department who makes things worse. I put money on there being plenty of "individuals" who are each responsible for patching different systems at Equifax, and while this particular breach was in system X, A-W might, at another time, have been the epicentre of a breach for similar reasons related to internal processes that make moving fast nigh on impossible. Now, while that's no excuse, I think the fault is likely not the individual who missed the patch, but the interaction between departments with different goals (political and practical) combined with an internal structure that makes changes glacially slow, and this sort of breach inevitable. |