A Change Has Already Come...
If the recent info-hacks at Bell Canada are any indication, those in positions to know better are usually the dumbest of the bunch. It's GUARANTEED that it's going to happen again. Corporate greed, stingy-claw profit raking policies, and willful ignorance of the basic problem scenario are the the prime culprit motivations leading companies down the public Walk of Shame in the last Eon. Now, I've been a web developer for (roughly) the last thirty years, and I was as guilty as these goony-ass Corporates in dismissal of Security as a factor of importance in the overall Bottom-line. Only after the third or fourth hack, was I truly pissed-off enough to find out the various ways it was happening and then develop a program to work from the ground-up to harden my security perimeters for a good bit of piece-of-mind.
For corporations that have billions of dollars at their disposal, the penny-wise bean counting employed in the last decade are coming back to not just bite them on the ass, but eviscerate their entire flanking as far as market share and customer trust/satisfaction. I'm pretty sure I have knowledge of the prime suspect in this recent digital chicanery; the deprecated usage of MySQL functions relating to database interactions. As it was officially deprecated in PHP v5.5 and removed in PHP v7, the lack of upgrade of many enterprise-grade scripts and code applications remains a joke of a travesty amongst the Fortune 500.
If not for outright stupidity, why are companies that can afford the overhaul of enterprise-crucial components so lax at implementation? In fact, this is what's causing the real problem as even decently-abled coding folk like myself could see three real ways to deal with these oft-repeated episodes recently. It's funny that no one working at any of these companies has any command of either PHP/PDO (PHP Data Objects) or BCrypt password-hashing in relation to database security. The two elements that'd lockdown database security nicely. PHP 5.5 introduced the concept of password hashing whereby an algorithm is applied to an inputted user password in the MySQL database table to irreversibly scramble it.
Meaning, even if the database was stolen and then dropped, the attackers couldn't harvest user passwords for extended-periods of cyber-mayhem. Combine this layer of security with the usage of PHP Data Objects, a Database Access Abstraction Layer, allows you to not only access multiple database types (MySQL, MS SQL, Oracle, PostgreSQL, etc.), but also the ability to block SQL injections by using prepared statements which seperate the code from the data (the ROOT CAUSE of the injection exploit).
With the previously-mentioned levels of database/site security, it's flabbergastingly lax to not cycle-in trained Web Professionals who understand these sorts of issues and harden against them. I know for a fact that a good number of serious hacks against my VREs were repulsed by my usage of those three layers. Now, you couldn't get me to use something without the employment of any of those factors. Why is it that those who are the target of these kinds of attacks are still leaving their rears exposed? Hey, must be the Money (lol!). For many of the Fortune 500 still using deprecated MySQL function-driven enterprise-coding, it should've been a wakeup call for their collective IT. Now, there are NO EXCUSES...