If "learn" is "has seen and memorized a checklist", then maybe. Don't expect people that "learned" like that to be able to do much in practice with that though.

Yeah. Security is best learned after creating software for four or five years. Before that you're not going to have enough of the pieces to think about it creatively. Things turn into "rules-games" where everyone else has to tell you the rules. Also, I think studying data science is underrated for cybersec.

As a cybersec consultant with experience working with many security organizations, I wholeheartedly disagree. There is a lot more to security than things that have to do with software engineering. In my experience, the companies with the worst security are ones that primarily employ current or former software engineers as leaders of their security teams with a misguided mentality that security is just a subset of software engineering. Because of that mentality, they tend to focus on a very small portion of security principles.

Most vulnerabilities include or source from some sort of poor software engineering though, which may root from said issues, among other things. Most of these vulnerabilities (including some hardware vulnerabilities) are discovered and exploited with clever, creative software engineering / exploit development.

I know cybersec is extremely broad, but I think software engineering plays an extremely important role.

I certainly agree it's an important part of security, but that's vastly different from "you should have 4 years of engineering experience before you can start learning security".

Speaking practically, the vast majority of companies that experience one of the vulnerabilities you are referencing are not going to be patching the code themselves - they're going to be updating their infrastructure with code that was written by someone else. And before they even get to that point, they are going to have to have policies/procedures that alert them of that vulnerability, that assess how important patching that vulnerability is, that determine cost of patching/not patching, that determine how to receive that patch, and that determine how to apply that patch. And all of those things involve much more than programming.

One of the other largest parts of defending a company from being hacked is training and protecting employees from social engineering/phishing attacks, and that's something that doesn't involve writing any code (or even knowledge of code) at all.

Fair points, thanks!

> There is a lot more to security than things that have to do with software engineering.

I didn't say there weren't?

> In my experience, the companies with the worst security are ones that primarily employ current or former software engineers as leaders of their security teams with a misguided mentality that security is just a subset of software engineering.

Wasn't what I was advocating for.

I'm advocating for learning security after you have a base of software development. Not leading a security team with no experience learning or practicing security. Also, this is a huge and growing field, so I'm speaking generally, but I'm sure there are sub-areas where there are counter examples.

For instance?

Training and awareness, asset management, third party management, policies and procedures, legal (you should have lawyers looking over HIPAA/PCI/GDPR stuff, not a programmer), identity management, incident response, recovery & business continuity, communications plans, PR...

I could keep going. All of these things could have some software engineering component, such as with identity management: there is a component there that deals with (for example) writing code to integrate your web app with multi-factor authentication, but identity management also encompasses things like writing good access control policies, managing the legal requirements for access, training people on how to use that multi-factor auth, etc.

Engineering skills are of course of great use if you are talking about the security of a specific codebase or doing penetration testing or doing the nitty-gritty customization of a security application, but "cybersecurity" is much more than that.

From my experience I agree. Physical, legal and network controls often get neglected.

There are a number of organizations that apply data science, ML, and HPC to support cybersec operations. The ones I am familiar with would likely consider an MS in CS to be a good entry point. A candidate that also had another substantial degree would be of even greater interest.

>Also, I think studying data science is underrated for cybersec.

Can you elaborate? I know a lot of security teams will have large amounts of machine data thrown into ELK or Splunk, but that seems like qualitative data and so there's not a lot of number-crunching to do.

There's just so many things that are helpful from data science.

Graph Analysis => Saw some guys turn the Android codebase into a graph and use that to turn a dozen minor exploits into a chain that gave them root. Pwn2own IIRC.

Statistics => Great for detecting anomalies / understanding how to evaluate manipulation of cyber adjacent systems. For example, understanding the beta distribution lets you figure out how someone will game ratings in your app store to beat out legitimate apps with similar sounding ones. And of course all of these things cut both ways: if you're on red team it helps you masquerade more effectively.

Recommenders => Obviously useful to understand from attack detection, spam filter evasion, etc.

Linguistic analysis => De-anon attackers by the language they use. Figure out automatically which email accounts have been owned by sudden changes in speech usage.

Things like fraud detection come to mind. Being able to build a model based on previously detected bad actors and then use that model to detect possible additional bad actors is a specialized but useful skill in some contexts.

Statistical anomaly detection is quite valuable.

if you have enough qualitative data it becomes quantitative data and you can start do fun stuff with that

The "already a programmer" thing is quite a misconception here. Security has many topics and domains that have nearly no crossover with being a programmer. It's possible that many people entering this degree program have no past (or future) experience writing code.

Anecdotally, at my (one of the largest in the world) security consulting firms that hires from similar degree programs, a very small minority of people have any experience as a programmer, and a similarly small minority of our work involves writing/reading any code.