How I'd start training in cybersecurity today

"What do I need to study to work in cybersecurity?"

It's a question that comes up a lot, and it rarely comes alone. The options follow straight after: Computer Engineering? A specialised cybersecurity degree? A master's? Certifications? Courses? Learning on my own?

I don't think there's a perfect path. There are very good security professionals who came from computing, but also from telecommunications, mathematics, law, risk management, other branches of engineering, communication or psychology. And there are excellent people who taught themselves. Each route leaves different strengths.

But if someone asked me what I'd choose to build a technical foundation from scratch, my answer would be fairly clear: I'd study Computer Engineering again.

In this article I explain why, and also why that doesn't make it the only way in. It's my opinion, based on how I trained and on what has served me since, working in security. Someone with a different path may well see it differently, and with good arguments.

Before learning security, I had to learn what I was protecting

I'm a computer engineer, and I've always been pretty curious about technology.

I like understanding what happens underneath: how two systems talk to each other, why something that worked stops working, how the things I use every day are built. I've told in another article how, as a kid, I tinkered with the computer until I broke it and then tried to fix it. Looking back, I think that explains fairly well why I ended up in cybersecurity.

I had no mapped-out plan to end up here. I had curiosity about how things worked, and the degree was a fairly direct way of feeding it.

What a degree like Computer Engineering gives you is exposure to many pieces at once: programming, networks, operating systems, computer architecture, databases, algorithms, mathematics and software engineering.

You don't come out an expert in everything. But you start building a map.

That map is what has served me most since. You know that an application talks to a database over a network, that it runs on an operating system, that someone has to authenticate to use it, and that all of it is deployed on infrastructure someone else designed. You may not master every piece, but you know it exists, roughly how it fits with the others and where to start looking when something doesn't add up.

For me, security comes after

Almost everything I do in security rests on something I learned earlier which, at the time, had nothing to do with security.

First you understand how a network works: addressing, routing, which service listens on which port. Then you understand much better why segmentation matters, what it means for something to be exposed and what a firewall is actually doing.

First you understand how an application is built. Then you understand its vulnerabilities, because you know where they come from: an input nobody validated, a badly handled session, a dependency nobody updated.

First you understand authentication, protocols and how an identity is managed. Then talking about Zero Trust or Conditional Access makes far more sense, because you see them for what they are: decisions about who gets access to what, and under which conditions.

First you understand how information is stored and how it moves between systems, people and services. Then you can talk with more judgement about data loss prevention (DLP) and information protection.

I don't want to overstate the order either. Nobody masters every layer before touching anything security-related, and often it's security itself that pushes you to understand what lies underneath. But when someone learns to operate security tools without knowing what system is in front of them, it eventually shows: when interpreting an alert, when proposing a control that breaks something in production, or when explaining a risk without really knowing where it comes from.

What about specialised cybersecurity degrees?

I wouldn't rule out a degree because it's called "Cybersecurity". There are well-designed curricula, and it makes sense that they exist.

What I'd do is read the curriculum carefully. And the question I'd ask is: how much computing am I going to learn?

I'd look at how much weight programming, networks, operating systems, architecture, databases, cloud, mathematics and logic, and software engineering carry. If all of that is well covered and security is built on top, it seems a very reasonable option to me.

The name of the degree worries me little. What would worry me is sacrificing too much foundation to reach specific security tools too early.

Learning a tool isn't the same as understanding the system it works on. Tools change every few years, while the fundamentals of a network or an operating system change much more slowly. When the tool of the day disappears, it's the latter that stays with you.

And master's degrees?

For me, a master's makes most sense as specialisation: going deeper into an area, putting order to what you already know and gaining a structured view of a specific field.

That's why I think it pays off most when it comes after a prior foundation. That foundation doesn't have to be Computer Engineering. It can come from telecommunications, other engineering disciplines, mathematics or years of professional experience in systems or networks. And if the master's is in governance, risk or compliance, the right foundation may be something quite different. It depends a lot on the programme and the area.

Where I find it harder is when a master's is used as a substitute for the fundamentals in a technical profile. Some people manage it, with a lot of effort, but a master's usually takes for granted things that, if they're missing, are hard to catch up on along the way.

Certifications do have value

I hold several certifications, including Microsoft's AZ-500 and ISO/IEC 27001 Lead Auditor, and I see value in them.

A good certification forces you to organise what you know, to go deeper into a technology or a specific framework and to work through domains you'd probably skip on your own. It also serves to show that you've studied a given area and to steer you towards specific technologies when you want to specialise.

What a certification doesn't do is replace experience.

You can get certified in Microsoft security without ever having designed a complex environment. You can know ISO 27001 well without having lived through a difficult implementation, with internal resistance, deadlines that don't fit and controls that looked simple on paper. A certification shows you've studied something. Experience comes when you apply it in a real environment and see where it goes wrong.

So I see them as a very useful way to structure and demonstrate knowledge. My only reservation comes when they're used as a shortcut to skip the foundation.

Courses solve a different problem

Courses are very useful when you already know what you want to learn: Azure, Active Directory, malware analysis, Kubernetes, risk management, cloud security or application security.

Their great advantage is that someone has already done the work of ordering the journey. It saves you a lot of time jumping between scattered documentation without knowing what comes first.

The risk appears when they pile up without a common foundation. You can end up with twenty courses done and the feeling of knowing lots of loose things that never quite connect. Each course teaches you one piece, but none explains how they all fit together.

That's why I come back to the map. If you already have an idea of how everything fits, each course puts a piece in its place. Without a map, it's easy to end up collecting pieces.

The part nobody can do for you

There's one part of training that doesn't depend on the path you choose, and for me it's probably the most important.

Technology changes. Products change name, licensing and behaviour: Azure Active Directory is now called Microsoft Entra ID, and it wasn't just a rename. Architectures change. Regulation changes: not so long ago hardly anyone talked about managing artificial intelligence, and today there's a standard like ISO/IEC 42001 and a European regulation that applies in phases.

And you'll constantly find yourself in front of something you don't know: a product you haven't used, a protocol you don't remember, a new regulatory requirement or an incident unlike anything you've seen.

There's no syllabus for that. There's official documentation to read patiently, labs to build and break, blogs and papers by people who have already fought the same problem, tests that don't work first time and many hours of research. Mistakes are part of the process, and in a lab they come cheap.

A degree, a master's or a certification can give you method and good foundations, and that helps a lot. But the habit of sitting down in front of something new and understanding it on your own is only built with practice. I think it's one of the few things that stays with you throughout your working life, whichever way you came in.

There's a lot of cybersecurity beyond purely technical profiles

Almost everything above I say with technical profiles in mind. Cybersecurity is much broader than that, and I don't want this article to read as a barrier to entry.

In governance, risk and compliance (GRC), privacy, legal, third-party management, training or awareness, a computing background helps, but it isn't the only thing that counts. Legal judgement counts too, as does the ability to analyse risk, to understand how an organisation works from the inside, to communicate and to change habits.

A lawyer specialised in technology can contribute an enormous amount in privacy, supplier contracts or regulatory compliance. Someone coming from the world of risk can build an excellent career in GRC. A person with a background in communication or psychology can contribute a great deal in awareness, which in the end is about changing behaviour, something an engineering degree barely covers.

On the technical side there are also great professionals who are self-taught or who came from telecommunications and other engineering fields. Good teams benefit from that mix: a team where everyone studied the same thing tends to see the same problems and to miss the same ones.

And as I explained in the article on leadership, much of what decides whether a project succeeds isn't technical. That isn't learned in any networking module either.

If I started today

If I had to start from zero with the aim of working on the technical side of security, this is roughly what I'd do. I'm describing how I would do it, with what I know now, without claiming it works for everyone:

1. I'd study computing. I'd choose Computer Engineering again and try to touch many areas, including the ones that didn't seem useful at the time.
2. I'd program, even without wanting to be a developer. Reading and writing code changes how you understand any system and any vulnerability.
3. I'd learn networks, systems, databases, architecture and identity properly. They're the layers almost everything else is later applied to.
4. Then I'd go deeper into security, in whichever area attracted me most: networks, cloud, identity, applications, pentesting, malware or GRC.
5. I'd use courses to speed up, certifications to structure and perhaps a master's to specialise.
6. And I'd keep learning on my own, because that part never ends.

Nor would I be in a hurry to specialise. If a young person were torn between building a broad computing foundation first or specialising as soon as possible, my view is that I'd build a good foundation first. Specialisation comes, and it comes better when there's something underneath it. I understand that some people think the opposite, especially if they're already very clear about what they want to do.

This is how I see each route. It's how I'd use them, not an objective ranking:

The question I'd ask myself

I think the really important question isn't which qualification you need to work in cybersecurity.

It's this one: am I building enough of a foundation to understand whatever I'll one day have to protect?

There are many ways to do that.

Computer Engineering was mine.

And if I had to start again, I'd probably choose it again.

Toni

This is a courtesy translation of the Spanish original. Antonio Cebreiro Bernárdez is a computer engineer and cybersecurity consultant. His specialisms, certifications and background are on his author page.