How to get started in cybersecurity from scratch: fundamentals, labs and career branches

What cybersecurity looks like day to day

The image of someone breaking into systems from a black screen is a tiny part of the job. Most of the work is understanding how a system works well enough to know where it can fail: reviewing configurations, reading logs, applying patches, designing permissions and responding when something odd appears. That is why you do not start with attack tools, but with the fundamentals those tools take for granted.

As a company that builds software and deploys it on AWS, what we see fail most is not sophisticated attacks but basic mistakes: keys pushed to repositories, overly broad cloud permissions, ports open for no reason and outdated dependencies. Someone who understands networking, Linux and how an application is deployed catches those problems before anyone exploits them.

A staged path with rough timelines

The timelines assume about 8 hours a week with lab practice. With fewer hours they stretch accordingly; if you already work in IT support, systems administration or development, you can move through the early stages faster. Keep in mind that landing a first role in the field usually takes well beyond these months: the fundamentals prepare you to specialise, they do not make you a specialist.

• Weeks 1 to 6: networking, the TCP/IP model, addressing, DNS, HTTP and traffic capture.
• Weeks 7 to 12: Linux from the terminal, permissions, processes, services and logs.
• Weeks 13 to 18: scripting with Bash and Python, and web security basics.
• Weeks 19 to 30: one branch, defensive or offensive, with labs and a write-up for each exercise.

Networking fundamentals

Almost every attack and almost every defence goes through the network. You need to know what happens when you type an address into the browser: DNS resolution, the TCP connection, the TLS handshake and the HTTP request. Also how addresses are assigned inside a network, what a firewall does and why an open port matters. Capture your own traffic with Wireshark and follow a connection step by step until every packet makes sense.

This stage feels slow because you are not “hacking” anything yet, and that is exactly where many people lose patience. It is worth it: later, when a tool shows an open port or an odd server response, you will understand what it means instead of copying the next command from a tutorial. If you have a router at home, review its settings and explain each option to yourself.

• The TCP/IP model and the difference between TCP and UDP.
• IP addressing, subnets and NAT.
• DNS, HTTP, HTTPS and how a certificate works.
• Ports, common services and firewall rules.

Linux and scripting

Most servers, security tools and labs run on Linux, so the terminal has to become comfortable. Learn to move around the file system, understand permissions and users, inspect processes and services, read logs under /var/log and filter text with grep, awk and pipes. Install a distribution in a virtual machine and use it daily for a few weeks, even if you are slower at first.

Next, learn to automate what you repeat. Bash is good for chaining commands and checking systems; Python for parsing logs, querying APIs or writing small tools. You do not need to be a developer, but you do need to read someone else’s script and understand what it does before running it, especially if you downloaded it from the internet. Many security tools are, at heart, scripts someone wrote to avoid repeating a job.

Your own labs and authorised platforms

All offensive practice happens in environments where you have explicit permission. The simplest option is your own lab: a virtualisation program, an attacker machine and one or more deliberately vulnerable machines on an isolated network, cut off from your home network. Free projects such as OWASP Juice Shop or DVWA are web applications built for risk-free practice.

There are also lab platforms and capture-the-flag competitions that provide machines to attack within their rules. Read those rules: they authorise their machines, not others. After each exercise, write a short report on what you found, how you found it and how to fix it. Those write-ups become your portfolio and train you for the most underrated part of the job: explaining a finding to the person who has to fix it.

• Set up a Linux server with SSH and harden it: keys instead of passwords, a firewall and automatic updates.
• Install a vulnerable application in your lab and document three OWASP Top 10 flaws.
• Write a Python script that detects repeated failed login attempts in a log file.
• Capture and explain in a document the traffic from a single visit to a web page.

Branches: defensive, offensive and what lies between

The defensive branch, often called blue team, covers monitoring, detection and response: security operations centres, log analysis, incident response and system hardening. The offensive branch, or red team, looks for flaws before a real attacker does through penetration testing, always with authorisation and a defined scope. Both are needed, and understanding one makes you better at the other.

There are less visible branches with plenty of demand: cloud security, application security for development teams, and governance, risk and compliance. If you come from programming, application security is usually the most natural way in. If you come from support or infrastructure, the defensive branch makes better use of what you already know.

Ethics and the law

Testing attack techniques on a system that is not yours and for which you have no written permission is illegal, even if you only want to “see if it works” and cause no harm. Most countries criminalise unauthorised access to computer systems; in Colombia, for example, Law 1273 of 2009 does so explicitly. That includes your neighbour’s network, your university’s platform and a company’s website.

In professional work, every test starts from an agreement that sets scope, dates and contacts. Bug bounty programmes work the same way: they only authorise what their policy includes. If you find something by accident, report it through the channel the organisation provides and do not exploit or publish it.

Common mistakes and how to choose a course

A useful beginner cybersecurity course spends its first modules on networking and Linux, not attack tools. Check the full curriculum, that it is up to date, that it includes guided labs and that it explains how to build your environment. If it is not in your first language, confirm it has subtitles. Be wary of any course that promises to turn you into a hacker in a few weeks.

No tool replaces judgement. Automated scanners report false positives and miss business-logic flaws, and certifications open doors in hiring processes but do not prove you can investigate a real incident. A course does not replace lab hours either. These are the mistakes that hold beginners back most.

• Starting with attack tools without understanding networking or Linux.
• Practising outside authorised environments.
• Running downloaded scripts without reading them.
• Collecting certificates without writing up what you practised.
• Trying to cover every branch at once.

Where the courses are

Frequently asked questions

Can I start in cybersecurity with no tech background?

Yes, but the road is longer because you first need networking, Linux and some programming. With about 8 hours a week, those fundamentals take 4 to 6 months. Many people enter the field after some time in IT support or systems administration.

Do I need to code to work in cybersecurity?

Not at a developer’s level, but you do need to read and write Bash or Python scripts. It helps you automate checks, analyse logs and understand what a tool does. In application security, on the other hand, coding well is part of the job.

Is it legal to practise ethical hacking at home?

It is legal if you practise on your own machines or on platforms that explicitly authorise you. Attacking any system you do not own without written permission is a crime, even if you cause no harm. Most countries have laws to that effect, such as Law 1273 of 2009 in Colombia.

Is it better to start with defensive or offensive security?

For most people, defensive, because there are more entry-level roles and it builds on what you learned in networking and Linux. Offensive security is more appealing to many, but it demands a broader technical base. What you practise in one helps in the other.

Do certifications replace hands-on experience?

No, although they help you get past screening filters. What convinces most in an interview is showing documented labs and reports on what you found and how you would fix it. Ideally, combine an entry-level certification with your own portfolio.