Security is a wide field, and the usual advice to beginners, "learn networking, then Linux, then everything else", is not much of a plan. Over the last months we published a series that covers the fundamentals and the day-to-day operations of security for people who build software. This post ties it together: the order we recommend, why each topic depends on the previous one, and how to practise without breaking the law or anyone's production system.

If you only have time for three posts, read the CIA triad, threats, vulnerabilities and risk and authentication and access control. They give you the vocabulary for almost every security conversation you will have at work.

How the topics fit together

Think of the series as four layers. Each layer assumes the one below it.

Layer 4  Design and culture      secure SDLC, threat modeling, zero trust
Layer 3  Operations              vulnerability management, monitoring, incident response
Layer 2  Domains                 web apps, cloud, endpoints, email
Layer 1  Fundamentals            CIA, networking, risk, attacks, crypto, access control

You can read layer 2 posts in any order once layer 1 is done, but layer 3 makes much more sense after you have seen where the vulnerabilities and alerts come from.

Layer 1: fundamentals

  1. Cybersecurity fundamentals: the CIA triad applied to real systems. Confidentiality, integrity and availability, plus authenticity and non-repudiation. Everything else in the series refers back to these properties.
  2. Networking basics for security. Addresses, ports, TCP and UDP, and how to see what your own hosts expose.
  3. Threats, vulnerabilities and risk explained. The words behind every security report, why CVSS is not your risk, and a small risk register.
  4. Common cyber attacks from the defender's side. Malware, phishing, denial of service, man-in-the-middle and injection, by the signs and the controls.
  5. Encoding vs encryption vs hashing. The cryptography building blocks and how TLS combines them. Case study: our "encrypted" passwords were Base64.
  6. Authentication, authorization and access control models. MFA factors, DAC, MAC, RBAC, ABAC and least privilege.
  7. Firewall, IDS, IPS, VPN and proxy explained. What each network control can see and stop.

Layer 2: security by domain

Layer 3: security operations

Layer 4: design and culture

A twelve-week study plan

One evening per week is enough if you combine reading with practice.

Week Read Practise
1 CIA triad Classify the data in one service you own
2 Networking basics Run ss -tulpn on your servers, scan your own public IPs
3 Threats and risk Start a risk register with five entries
4 Common attacks Turn on MFA everywhere you have an account; review email DMARC
5 Cryptography Check how your apps store passwords and verify webhooks
6 Access control Review who has admin in your cloud and source control
7 Network controls Draw your network and mark every control from the post
8 Web attack surface Work through a deliberately vulnerable app locally
9 Cloud and endpoint Run your cloud provider's security posture checks
10 Vulnerability management Scan one repository and one image, triage the findings
11 Monitoring and incident response Write one detection rule and a one-page runbook
12 Secure SDLC and zero trust Threat-model one upcoming feature with your team

Practising legally

Hands-on practice is essential, and it must happen on systems you own or are explicitly allowed to test. Scanning or attacking anything else, even "just to see", can violate laws and contracts in many countries. Good legal options:

  • Your own virtual machines. A laptop with a hypervisor or a few containers is enough for networking, hardening and log experiments.
  • Deliberately vulnerable applications that you run locally, such as OWASP Juice Shop, built for learning web security.
  • Capture the flag (CTF) competitions and training platforms that provide targets you are allowed to attack under their rules.
  • Cloud free tiers in a separate account for practising IAM, logging and storage policies, with a budget alert so experiments do not become bills.
  • Your company's systems only with written permission and an agreed scope, ideally with the security team.

Keep notes as you go: the command, what you expected, what you saw. Those notes become your own reference, and they are exactly the habit incident response depends on.

Using the series with a team

The series also works as a lightweight internal training programme. One format that worked well for teams we have helped:

  • Pick one post per fortnight and ask everyone to read it before a 30-minute session.
  • In the session, spend ten minutes on questions and twenty on the practice exercise, applied to one of the team's own systems.
  • Write down every finding in the team's backlog with an owner, the same day.
  • Rotate who leads the session, so security knowledge does not depend on one person.

After six months, most teams have closed a handful of real gaps, such as missing MFA, an unreviewed admin role or an untested backup, and have a shared vocabulary for security reviews.

What we deliberately left out

The series is defensive. It does not teach exploitation techniques or malware development, and it mentions ethical hacking only as a profession that works under explicit permission. If you want to go deeper into offensive security, do it through structured courses and legal platforms, and always with a clear scope.

Key takeaways

  • Learn in layers: fundamentals first, then domains, then operations, then design and culture.
  • Three posts give most of the vocabulary: the CIA triad, risk, and access control.
  • Pair each reading with a small exercise on your own systems.
  • Practise only on systems you own or are explicitly authorised to test.
  • Keep a written log of what you try; it is the same skill incident response needs.

References