Security Engineering: A Practical 12-Week Learning Roadmap

Security is not just about finding vulnerabilities. It is about designing systems that reduce risk, implementing effective defenses, detecting unusual behavior, and responding when something goes wrong.

Leia em português

This free series explains how that work happens—one practical lesson at a time. Our goal is to build a strong foundation in security engineering and apply it to realistic technical problems.

Who is this learning path for?

• People beginning their journey in cybersecurity.
• Software developers who want to build more secure applications.
• IT, network, and Linux professionals moving toward security roles.
• Cloud engineers seeking stronger security design skills.

You do not need a security job title to start. We explain the essentials before offering more advanced challenges.

What does a security engineer do?

A security engineer helps protect applications, infrastructure, identities, services, and data. Four questions guide the work:

1. What are we protecting? Identify the assets and their importance.
2. What could go wrong? Consider threats, mistakes, and failure scenarios.
3. How can we reduce the risk? Design controls such as least privilege, segmentation, encryption, monitoring, and tested backups.
4. How do we verify the defenses? Use tests, logs, reviews, and incident exercises.

Security engineering overlaps with Cloud Security, Application Security, Network Security, and DevSecOps. We will discover how these areas connect rather than treat them as isolated careers.

The 12-week learning roadmap

1. Week 01 — Security Fundamentals: confidentiality, integrity, availability, threats, risk, and defense in depth.
2. Week 02 — Network Security: TCP/IP, DNS, TLS, firewalls, traffic analysis, and segmentation.
3. Week 03 — Linux Security: permissions, SSH, logs, hardening, and monitoring.
4. Week 04 — AWS Identity and Access: IAM policies, roles, temporary credentials, and least privilege.
5. Week 05 — AWS Network Security: VPC, subnets, Security Groups, NACLs, and database isolation.
6. Week 06 — Data Protection: S3, KMS, encryption, backups, and recovery checks.
7. Week 07 — Application Security: OWASP risks, authentication, authorization, and secure coding.
8. Week 08 — API Security: OAuth 2.0, input validation, SQL injection, XSS, and access control.
9. Week 09 — Container Security: Docker images, permissions, vulnerabilities, and isolation.
10. Week 10 — DevSecOps: CI/CD, secrets, dependency scanning, and infrastructure as code.
11. Week 11 — Detection and Response: logging, CloudTrail, alert triage, and incident investigation.
12. Week 12 — Final Project: review and harden a small application and its infrastructure.

Each week includes five short sessions. The last one focuses on review and practice. The schedule is a guide, not a race.

How each lesson works

• 10 minutes — Concept: understand the vocabulary and why a control exists.
• 20 minutes — Practice: inspect a configuration, solve a scenario, or work in a safe lab.
• 10 minutes — Reflection: explain the risk, your decision, and how to verify the result.

Every lesson has two tracks: Essential, with simple explanations and a guided exercise, and Professional Challenge, with a more realistic engineering problem. Interactive questions and small simulations will help you test your understanding.

Learn the culture, not just the tools

Security changes constantly. Follow technical write-ups, incident reports, official documentation, and local communities. Explore the AWS Security Blog, the OWASP Top 10, the CISA Known Exploited Vulnerabilities catalog, and the OWASP São Paulo chapter.

Practice only in systems you own or in deliberately vulnerable training environments, such as PortSwigger Web Security Academy and OWASP Juice Shop. Never probe third-party systems without authorization.

What will you gain?

By the end, you should have stronger technical vocabulary, hands-on experience with common security controls, a documented set of exercises, and a small final project. Twelve weeks are not a promise of mastery or employment; they are a structured foundation for continued learning.

Warm-up challenge: Is a system secure just because it has a firewall? Reveal the answer.

No. A firewall is one control, not a security guarantee. You also need to understand the assets and threats, manage identities and permissions, patch software, protect data, monitor behavior, and prepare to respond to incidents. In the next lesson, we will turn that mindset into a concrete exercise.

Next lesson

Lesson 01 — What Does a Security Engineer Actually Do? We will explore the engineer’s mindset and ask what it really means for a system to be secure.

Start Lesson 01 — Practical Security Review →

Core references

• NIST NICE Framework
• AWS Well-Architected — Security Pillar
• OWASP Top 10