Sure, blame the consultants with their "booming industry". I'm sure T-Mobile spent adequate amounts of money on securing their data, hired all the best people, and it was all the security peoples' fault for not doing it properly.
I've been in security for over a decade. I currently work at a FAANG with nearly unlimited security budget. Previously I worked at another major tech company with nearly unlimited security budget. Before that I was a consultant and consulted at companies with huge security budgets. All of them, including my FAANG, struggle to have anything more than security that can only be described as "patchwork".
The truth is that nobody actually knows how to do security. Software devs are awful at it (the amount of FAANG engineers I know that don't even understand what encryption is, or think that hashing passwords is unimportant, would blow your mind), management is awful at prioritizing it or even knowing what to do in the first place, and every security professional in the industry is effectively just winging it based on what someone else in the industry promoted as "best practice" (and is probably outdated by now).
Sure, prolonged investment in security might help make things better, but that's not an overnight solution, and it might not be a solution at all given that the attackers are investing heavily in their methods, too. We have to do more than just acting like increasing the security department's budget is going to fix all of our problems. I guarantee it won't.
But that's not because there aren't also lots of devs who understand security, it's because FAANG companies have purposely chosen to prioritize hiring based on leet code ability above hiring based on security knowledge.
edit: This is why software developers would benefit from a union or licensing process, because currently devs who don't understand security are artificially lowering developer salaries by externalizing risk onto users.
a) Often not prioritized
b) Handled in the shadows by some other team
the engineers don't get exposed to it. Security hasn't gone through an 'operations' evolution where it melds with engineering so these problems aren't getting better.
Context: Am security professional
Other fields like web development, consulting, engineering, lawyers, medical field etc all have very established career development pipelines, where you can join as a junior employee and learn on the job from those around you to become a better professional.
Security on the other hand lacks this. In the vast majority of organizations I've been in, security roles are something that you are expected to enter with an already established level of experience, and then you are dropped on a project by yourself with little mentorship or training. This makes it almost impossible to bring new people into the field.
At my company, we have a "security champions" program that is intended to allow software engineers to dedicate some of their time to security and help their team think through security challenges. But we really struggle with this program, because my company pretty much just hopes that the engineers signing up to be champions are already experienced in security. If they are not, we do not have processes in place to train them, even if they do want the training.
And what's worse, is that I even see resistance to making it easier for junior people to learn security. If you spend much time on r/cybersecurity, a common thing you will see is people insisting that security should not be an entry level job, and that everyone should be required to spend 5-10 years as a sysadmin before you're even allowed to apply for a security role. I think that's ridiculous, and not only for the reason that being a sysadmin has a lot less overlap with the world of security than people like to think it does.
At what level? Are we talking like knowing the different ways to mitigate XSS and other basic OWASP top-10 style things, or having the ability to find the next Spectre or Meltdown?
One of the other issues I see is that we should be able to take the above-described candidate, which is maybe not exactly what we need but shows promise, and train/mentor them into the type of security professional that we need. But my company (and most others I've seen) are also just really bad at security training and career development. It's a real problem, IMO, that security is treated as an "experienced people only" industry, and is not very welcoming to people that aren't already experts but are willing and able to learn. We are trying to change this in my organization, but it's slow and challenging.
To be fair, from a devs perspective you need to flip it around in your brain, in order to go from e.g. "you need to sanitize user input to make it safe for a javascript context" to "seeing unsanitized user input that could be getting injected into a script." Even if you know all the right answers, it's still probably not going to come out super eloquently. (And I realize there are other and better answers also, but just to choose one that's easy to explain.)
Something needs to be done at a fundamental level and finding some easier qualification in terms of security professional before this problem could be fixed.
One easy way to fix it would be market economics. Make senior security roles paid grade a lot higher than comparative other similar software engineering roles. These incentives should balance things out in time.
Otherwise I am looking at security professional death spiral.
And second, non leet devs are not some kind of safety panacea. The worst are people who don't care at all. Many have not heard of basics.
Third, if you actually decide that security is important and try to learn it, you will find resources are rare. There is very little of it targeted at developers. There is no shared knowledge base. There are no commonly known processes. Nothing like that.
So even if you care and try, you end up learning very little.
Some folks will then further encrypt the stored hashes such that a database compromise, but not an application-server compromise, leaves the attacker without the keys necessary to decrypt even the hashes, but I am ambivalent about the usefulness of that (can't hurt, but the threat model for that seems more geared towards internal threats than external).
Sorry to make an example of you but this kind of attitude is the problem. Everyone does something security related. If something is giving input to the machine (that could be typing on a keyboard, collecting data from a sensor, or anything else), you have to care about security. Even if security means in your context sanitizing inputs to make sure you don't overflow and crash, or write something to the screen you're not supposed to, etc.
Modern machines work slightly differently. The key material is stored in a TPM which is a separate processor & dedicated memory that is purpose built to withstand physical and electrical attacks. Apple devices specifically have a complicated key wrapping scheme (protected by your pincode or password) to make certain files accessible/inaccessible depending on the policy defined (available after first unlock, available only when unlocked, available always, & a fourth one I forget). Your password is just used for protecting the underlying keys but the device actually generates strong key material that's used to protect all on-disk contents regardless of a password being present IIRC.
If you're talking about the password database for local login & whatnot, that was available without even having FDE by using PBKDF2 or similar to securely hash the password. That way you only store the hash & leaking that file doesn't mean that someone can reverse that back to get your password.
So true. A problem is that "spending money on security" is so nearly always a synonym for increasing the infosec budget under the CISO. Which is useful, yes, but only a partial solution. A bigger ROI would be to spend it on developers who are experts in security and building a culture that cares. But even in enterprise security companies (most of my career), product security is so often seen as a checklist that infosec will take care of, not a core engineering competency.
I could give $5 billion to my FAANG right now and I bet we'd still be breached (hell, I'm pretty sure we already have that budget in my FAANG's security department). The US DoD already has a cyber security budget of $10 billion, and they still get breached.
You underestimate the amount that these companies care about security. Just because they get fined "only" a couple hundred million dollars doesn't mean they aren't scared shitless by being breached. I've sat in boardrooms with CEOs telling us they were willing to pay whatever it takes to increase their security (and they put their money where their mouth is, too). They still get breached.
Budget isn't everything. Does it help? Sure. Like any other security professional, I can recount plenty of tales of teams deprioritizing security in favor of something else. Would they have done differently if they were incentivized better by bigger potential fines? Maybe. Would they have actually been able to implement ironclad security even if they did prioritize it? In the cases I've seen, it's doubtful.
edit: and consider this. If you truly do think that money is everything, you should realize that you will never be able to throw more money at your security than a nation state attacker like China will be able to throw at breaching your security. In the competition of who can spend the most money, you've already lost.
I remember my final conclusion, "Security" is a mindset, not a Product.
I guess this rhymes with what you said.
It's like the 2000 era adage, the terrorists only have to be right once.
Money flows (often) freely but it's not enough. I worked at one place where the CISO was very aware that security needs to be designed into the product ground up. Later a new CISCO came in who thought that security can be achieved merely by purchasing every security scanner on the market and sit back to bask in perfect security. Needless to say security was far worse with the latter one.
Destruction is easier than protection.
My experience both working at and with higher end consultancies is that there is no correlation whatsoever between those degrees and any particular consultant’s competency. Some of the best people I’ve worked alongside have been college dropouts and Religion majors.
If you're doing low level design of crypto algorithms, you need to know math. If you're doing appsec reviews or pentests, then a background in software development might help (but is not required).
But there is an entire world of security roles out there that are essential to implementing security that have nothing to do with math or compsci. The security industry right now has a huge problem with gatekeeping, where they think you can't even begin to think about security unless you're already a top-tier principal engineer, and it's led to a huge drought of talent in security roles across the board.
To this day, its hard for me to tell during hiring what makes a good security hire.
I'm going to bet that they did have qualified engineers, because I like to assume the best in people, but I also assume that those engineers may not have been able to make the changes they want to.
In my experience in big companies, corporate bureaucracy and a complete unwillingness to change processes or systems is usually a bigger hinderance to security than the skill level of consultants/engineers.
And they had the nerve to suggest we replace this unencrypted database, which an old legacy system needs entirely open root access to with something secure for an eye watering bill - we don't hire security consultants to replace our legacy systems, we pay them to stop unauthorised people accessing the big pile of data we leave in the open.
Get the gall - they even wanted us to change the interface between our two big legacy systems because it was just a CSV file which contained all our sensitive data on it. Wimps! Especially as we told them they could do anything to make our systems secure, as long as they didn't touch those legacy systems."
Because my degree is in Management Information Systems (MIS), but I've done troubleshooting on both performance problems of the O(n^5) variety and problems of the "not covered in the requirements document" variety... Not sure what else I need to understand, say, memory bounds-checking problems or firewall/ACL configuration problems.
EDIT: expanded acronym
I just say "business and computers and how they go together" when explaining it.
Of course, I never actually got certified because I left the role immediately afterward and never bothered following up. Moreover, I didn't really meet the requirements, which included having some tenure as a security professional. But I'm sure I could have finagled it if I had any interest in working security (I absolutely did not).
Braindump-able IT certs benefit no-one, and expecting people to have MSc degrees in infosec is elitist and very impractical.
Exactly. Heaven forbid we blame the corporations whose lax security led to the stolen data in the first place. That would make advertisers unhappy.
Something like that getting shipped to prod... yeah, you have the D team building tech at tmobile. So we should collectively be shocked if their codebase isn't a leaky sieve.