Pro Level Roadmap

Security Professional Project Guide

A practical guide for turning study into real projects, useful reports, and portfolio evidence.

This page is for the stage where reading notes is not enough anymore. Each project gives you a clear outcome, expected time, difficulty, general steps, completion tips, and the skills you should be able to explain after finishing it.

How to Use Project Method Project Ladder Portfolio Standard Back to Resources

How to Use This Guide

The time estimates assume 1 to 2 focused hours per day. If a topic is new to you, double the time and treat the first attempt as a learning build. A clean portfolio version can come after you understand the work.

  • Complete the projects in order if you want a full security professional path.
  • Pick only one track if you already know your direction, such as blue team, app security, cloud security, or automation.
  • Finish with evidence: screenshots, configs, diagrams, command output, scripts, reports, and a short reflection.
  • Keep the scope legal and controlled. Use your own lab, intentionally vulnerable machines, or systems where you have written permission.
Important: A project is not complete when the tool runs once. It is complete when you can explain the goal, architecture, tests, failures, final result, and what you would improve next.

The Repeatable Project Method

Use this same pattern for every project. It keeps the work professional and stops the project from becoming random tool usage.

1. Define the outcome Write one sentence that says what the project proves. Example: "This lab detects SSH brute-force activity and produces an incident report."
2. Draw the scope List the machines, networks, users, data sources, tools, and what is intentionally out of scope.
3. Build the lab Create snapshots, baseline configs, and a clean folder structure before changing anything.
4. Test with evidence Run normal tests and failure tests. Save command output, screenshots, logs, and notes as you go.
5. Fix and retest Do not stop at the first working result. Break it, tune it, handle errors, then prove it still works.
6. Write the report Explain the problem, architecture, steps, result, limitations, lessons learned, and next improvements.

Project Ladder

01. Operating Systems - Hardened Workstation and Investigation Baseline

Time: 5 to 7 days Difficulty: 2/5 Best for: OS foundations

Goal: Build a Windows or Linux VM, harden the basics, capture a clean baseline, then prove you can notice meaningful changes.

Open project plan

General steps

  1. Create a VM, update it, and take a clean snapshot.
  2. Document users, groups, running services, startup entries, open ports, installed packages, and firewall state.
  3. Apply basic hardening: least privilege, strong passwords, updates, firewall rules, audit logging, and unnecessary service removal.
  4. Create a "before and after" baseline using tools such as Task Manager, Event Viewer, PowerShell, systemctl, journalctl, ps, ss, and netstat.
  5. Simulate safe changes, such as a new user, a new scheduled task, or a new listening service, then detect and explain the difference.
  6. Write a short investigation checklist for this system.

Tips

  • Change one thing at a time so your notes stay readable.
  • Keep the original baseline untouched. If you get lost, restore the snapshot and repeat cleanly.
  • Separate hardening notes from investigation notes. They answer different questions.

What you learn

  • How operating systems expose users, processes, services, logs, and network activity.
  • Why baselines matter in incident response and troubleshooting.
  • How small local changes can create security and reliability risk.

02. Networking - Segmented Lab Network with Firewall Rules

Time: 2 to 3 weeks Difficulty: 4/5 Best for: network security

Goal: Build a small lab with separate networks for workstation, server, and guest or attacker traffic, then control access with routing and firewall rules.

Open project plan

General steps

  1. Draw the topology first: subnets, gateways, firewall, server, client, and test machine.
  2. Create a simple IP plan with gateway addresses, DHCP ranges, static server IPs, and DNS notes.
  3. Build the lab with tools such as VirtualBox, VMware, GNS3, Packet Tracer, pfSense, or Linux routing.
  4. Configure routing, DHCP or static addressing, DNS, NAT if needed, and default deny firewall rules.
  5. Allow only specific traffic, such as workstation to web server on 80/443, and block the rest.
  6. Validate with ping, traceroute, curl, nmap, tcpdump, Wireshark, and firewall logs.
  7. Document a rule table that explains source, destination, port, action, and reason.

Tips

  • Troubleshoot in layers: link, IP address, gateway, route, firewall, service, DNS.
  • Use default deny and add only the rules you can explain.
  • Save packet captures for both allowed and blocked traffic.

What you learn

  • How segmentation reduces blast radius.
  • How routing, NAT, VLAN-style separation, and ACL thinking fit together.
  • How to prove a network control works instead of assuming it works.

03. Linux and Shell - Log Triage Automation Toolkit

Time: 4 to 7 days Difficulty: 3/5 Best for: command-line fluency

Goal: Write shell scripts that parse logs and produce useful security summaries instead of raw noise.

Open project plan

General steps

  1. Collect sample logs from auth.log, syslog, web server access logs, or lab-generated logs.
  2. Define the questions your script answers: top failed login IPs, unusual usernames, HTTP status spikes, or suspicious command history.
  3. Build small pipelines with grep, sed, awk, sort, uniq, cut, head, tail, and date filters.
  4. Wrap the useful pipelines into a script with arguments, help text, error messages, and output files.
  5. Generate a markdown or text report with findings and timestamps.
  6. Test against normal logs, empty logs, malformed lines, and very large files.

Tips

  • Start with one log type. Add more only after the first parser is reliable.
  • Never destroy original logs. Write output to a separate report directory.
  • Make the script useful for future you: add usage examples at the top.

What you learn

  • How to turn raw operational data into quick security answers.
  • How shell tools work together in real response workflows.
  • How to write scripts that survive imperfect input.

04. Programming and Automation - Security Automation CLI

Time: 2 to 3 weeks Difficulty: 4/5 Best for: Python and tooling

Goal: Build a small command-line tool that accepts targets, runs safe checks, stores structured results, and creates a readable report.

Open project plan

General steps

  1. Choose a safe scope: your own domain, local lab IPs, or offline sample files.
  2. Design input and output first. Decide what the tool accepts and what JSON or markdown report it produces.
  3. Use modules for collection, parsing, reporting, logging, and configuration.
  4. Add defensive behavior: timeouts, clear errors, dry-run mode, and rate limits.
  5. Write basic tests for parsers and report generation.
  6. Package the tool with a README, examples, and a sample output report.

Tips

  • A boring reliable tool is better than a flashy tool that breaks on the second input.
  • Store raw results and processed results separately.
  • Keep scanning behavior gentle and authorized. Passive checks are enough for a first portfolio project.

What you learn

  • How automation projects should be structured and documented.
  • How to convert security tasks into repeatable workflows.
  • How error handling, logging, and output design make tools professional.

05. Security Fundamentals - Risk Assessment and Control Plan

Time: 5 to 10 days Difficulty: 3/5 Best for: security thinking

Goal: Build a realistic risk assessment for a fictional small company and propose controls that match the business.

Open project plan

General steps

  1. Choose a simple company profile, such as a clinic, school, SaaS startup, or local shop.
  2. List assets: users, laptops, servers, cloud accounts, customer data, payment data, backups, and third-party services.
  3. Identify threats and vulnerabilities for each major asset.
  4. Score likelihood and impact using a simple low, medium, high model.
  5. Map controls to the biggest risks: MFA, backups, patching, least privilege, logging, endpoint protection, training, and incident response.
  6. Write a 30, 60, and 90 day remediation plan.

Tips

  • Do not recommend expensive controls without explaining why the business needs them.
  • Risk is about tradeoffs. Show cost, difficulty, and expected benefit.
  • Keep language understandable to non-technical readers.

What you learn

  • How security connects to business reality.
  • How to prioritize instead of treating every issue as equally urgent.
  • How governance, risk, and technical controls support each other.

06. Blue Team, SOC, and SIEM - Mini Detection Lab

Time: 2 to 4 weeks Difficulty: 4/5 Best for: detection engineering

Goal: Send endpoint or server logs into a SIEM, create detections, tune false positives, and write an incident-style report.

Open project plan

General steps

  1. Deploy a lab SIEM such as Wazuh, Elastic, Security Onion, Splunk Free, or another safe local setup.
  2. Onboard at least one Linux source and one Windows source if possible.
  3. Generate controlled events: failed SSH logins, suspicious process execution, web scanning, privilege changes, or blocked firewall traffic.
  4. Write detections that explain the logic, data source, condition, severity, and expected false positives.
  5. Create a dashboard for authentication, process, network, and alert trends.
  6. Write one incident report from detection to triage, evidence, containment recommendation, and lessons learned.

Tips

  • Detection starts with data quality. Confirm logs are arriving before writing rules.
  • Keep normal activity in the lab too. You need it to tune false positives.
  • Every alert should answer: what happened, where, why it matters, and what to do next.

What you learn

  • How telemetry becomes detection logic.
  • Why false positives are an engineering problem, not just an annoyance.
  • How SOC analysts move from alert to evidence-backed conclusion.

07. Web and Application Security - Vulnerability Report and Secure Fix

Time: 2 to 3 weeks Difficulty: 4/5 Best for: appsec fundamentals

Goal: Test an intentionally vulnerable app, document findings, fix or mitigate selected issues, and prove the fixes work.

Open project plan

General steps

  1. Use a legal lab target such as OWASP Juice Shop, DVWA, WebGoat, or your own small app.
  2. Map the app: routes, roles, login flow, forms, API calls, cookies, and trust boundaries.
  3. Test common issues: broken access control, injection, XSS, weak sessions, file upload risk, insecure headers, and information leakage.
  4. For each confirmed issue, capture the request, response, impact, and reproduction steps.
  5. Fix or mitigate selected issues, then retest the exact exploit path.
  6. Write a report with severity, evidence, affected component, remediation, and verification.

Tips

  • Do not list theoretical vulnerabilities as findings. Findings need evidence.
  • Use the browser devtools and an intercepting proxy to understand requests before trying tools.
  • Retesting is part of the project. A fix without proof is not finished.

What you learn

  • How HTTP, sessions, authentication, authorization, and input handling work in practice.
  • How to write reports that developers can actually use.
  • How secure coding and testing connect.

08. Cloud, Virtualization, and DevOps - Secure Landing Zone

Time: 3 to 5 weeks Difficulty: 5/5 Best for: cloud security

Goal: Build a small cloud or virtualized environment with infrastructure as code, network boundaries, logging, secrets handling, and deployment discipline.

Open project plan

General steps

  1. Choose a safe platform: local virtualization, a free-tier cloud account, or a sandbox subscription with strict budget alerts.
  2. Design a basic architecture: public entry point, private app or server tier, admin access path, logs, backups, and monitoring.
  3. Define infrastructure using Terraform, cloud templates, Docker Compose, Ansible, or another repeatable tool.
  4. Apply least privilege for identities, restrict security groups or firewall rules, and avoid hard-coded secrets.
  5. Deploy a small app or service, then validate reachability, logging, backup, and recovery behavior.
  6. Run a security review: exposed ports, IAM permissions, secret storage, patching, monitoring, and cost risk.

Tips

  • Set budget alerts before creating resources in any paid cloud.
  • Write a destroy or cleanup procedure on day one.
  • Small and repeatable beats large and fragile.

What you learn

  • How cloud networking, identity, deployment, and monitoring interact.
  • Why infrastructure as code improves review and recovery.
  • How security mistakes become operational and cost problems in cloud environments.

09. Cryptography and Identity - PKI and Access Control Lab

Time: 2 to 4 weeks Difficulty: 4/5 Best for: trust and access

Goal: Build a small trust system with certificates or SSH keys, enforce access rules, rotate credentials, and document the identity flow.

Open project plan

General steps

  1. Draw the trust model: users, services, certificate authority or key authority, and protected resources.
  2. Create a local CA or key management process in a lab environment.
  3. Issue credentials for a server and one or more clients.
  4. Configure TLS, mutual TLS, SSH certificate authentication, or role-based access in a small service.
  5. Test valid access, invalid access, expired credentials, revoked credentials, and rotated credentials.
  6. Write a simple operations guide for issuing, rotating, revoking, and auditing access.

Tips

  • Do not treat keys as magic files. Document who owns them, where they live, and how they are protected.
  • Practice failure cases. Identity systems are judged by how safely they fail.
  • Keep private keys out of screenshots and public repos.

What you learn

  • How encryption, authentication, authorization, and trust chains differ.
  • How certificates and keys are managed over time.
  • Why identity is one of the most important security control planes.

10. Projects and Portfolio - Capstone Case Study

Time: 1 to 2 weeks Difficulty: 3/5 Best for: professional proof

Goal: Turn one completed project into a polished public case study that proves your thinking, not just your tool usage.

Open project plan

General steps

  1. Choose the strongest completed project, preferably one with architecture, testing, and a written result.
  2. Clean the repository: remove secrets, remove noisy files, add a license if appropriate, and organize folders.
  3. Create a clear README with problem, goals, architecture diagram, setup, usage, tests, screenshots, and limitations.
  4. Write a case study that explains what you tried, what failed, what you fixed, and what you learned.
  5. Add proof: screenshots, sample reports, config snippets, sanitized logs, and short diagrams.
  6. Prepare a 2 minute explanation for interviews.

Tips

  • Do not publish secrets, real personal data, private IPs from someone else's environment, or anything you do not have permission to share.
  • A good portfolio project has a beginning, a decision trail, and a finished result.
  • Interviewers care about what you can explain under questioning.

What you learn

  • How to communicate technical work professionally.
  • How to show judgment, tradeoffs, and evidence.
  • How to turn practice into credible career material.

Portfolio Standard

Use this checklist before calling any project finished. It keeps the work useful for revision, interviews, and future expansion.

README Problem, scope, prerequisites, setup, usage, screenshots, limitations, and cleanup.
Architecture A simple diagram showing machines, networks, data flow, trust boundaries, and tools.
Evidence Commands, output, screenshots, logs, configs, reports, or packet captures that prove the result.
Reflection What worked, what failed, what you changed, what you learned, and what you would improve.
Safety Secrets removed, lab scope explained, legal target confirmed, and cleanup steps included.
Interview Story A short explanation of the project goal, your approach, the hardest issue, and the final outcome.
Simple rule: If someone can rebuild the lab, understand your decisions, and see proof of the outcome, the project is portfolio-ready.