RMFInsider

The five cybersecurity portfolio projects that get entry-level candidates hired are: a home SIEM with at least one detection you wrote yourself, a vulnerability scan with a documented remediation, a virtual machine you hardened against a STIG with a before-and-after checklist, an incident response tabletop you designed and ran, and a control mapping that ties a real system to a framework like NIST 800-53. Each one produces a written artifact you can hand to an interviewer, each one maps to a specific job family, and none of them requires more than a laptop with 16 GB of RAM and free software.

A portfolio matters for entry-level candidates because it is the only evidence you have. A certification says you can pass a test. A project says you can do the work and, more importantly, write it up in a way somebody else can follow. I review packages and assess evidence for a living as a DoD ISSO, and the same instinct that makes an assessor trust an artifact makes a hiring manager trust a portfolio: dated, specific, reproducible, and honest about what did not work.

What makes a portfolio project count

Before the list, the standard. A project that counts has four properties. If yours is missing one, fix that before you start a new project.

• A written deliverable. A report, a runbook, a checklist, a mapping document. Not a screenshot dump. Two to five pages, written for a manager who has ten minutes.
• Evidence with context. Screenshots that include a hostname, a date, and a visible result. A before state and an after state.
• A decision you made. Why you chose this detection, why you accepted that risk, why you did not apply that STIG rule. Interviewers hire judgment, not clicking.
• A limitation you admit. “I could not get the agent to forward Sysmon events over TLS, so I used plaintext on an isolated network and noted it as a gap.” That sentence has landed more offers than a flawless-looking project ever will, because it sounds like someone who has done real work.

Project 1: a home SIEM with a detection you wrote

Maps to: SOC analyst, security operations, detection engineering, and cleared CSSP analyst roles.

Stand up Wazuh (free, open source) or the Elastic stack on one virtual machine, enroll a Windows endpoint and a Linux endpoint, and ship logs to it. The Wazuh SOC analyst home lab walkthrough gets you there in a weekend. That alone is table stakes; the part that gets you hired is what you do next.

• Install Sysmon on the Windows endpoint with a public configuration and confirm the events arrive.
• Simulate one attacker behavior: a PowerShell download cradle, a new local administrator account, five failed logons followed by a success. Nothing exotic.
• Write one custom rule that fires on that behavior. Document the rule logic, the false positive risk, and how you tuned it.
• Produce a one-page “detection note”: what it catches, what it misses, which MITRE ATT&CK technique it maps to, and what a tier 1 analyst should do when it fires.

The interview payoff: “walk me through an alert you would investigate” becomes a story about a rule you wrote, tuned, and documented, instead of a recitation of what you read about SIEMs.

Project 2: vulnerability scan with a documented remediation

Maps to: vulnerability management analyst, ISSO, GRC analyst, systems security roles. This is the project I recommend to anyone targeting the DoD or federal lane, because it is the daily reality of the job.

• Build a deliberately unpatched Windows or Linux VM (an older build, a few default services enabled).
• Scan it with a free vulnerability scanner. Export the results.
• Select five to eight findings across severity levels. For each, write the finding, the plain-English risk, the fix, and the evidence the fix worked (rescan result, configuration screenshot with hostname and timestamp).
• Deliberately leave one or two findings open, and document them as accepted risk or scheduled remediation with a due date and a justification. That is what a real plan of action and milestones looks like, and how to write a POA&M shows the format DoD uses.
• Track the whole thing in a spreadsheet: finding, severity, owner, milestone, due date, status, closure evidence.

The interview payoff: you can talk about CVSS, about why the same finding shows up on three hosts, about the difference between remediating and mitigating, and about documenting a risk decision. That is 80 percent of a vulnerability management interview and a solid third of an ISSO interview.

Project 3: STIG-harden a virtual machine

Maps to: ISSO, systems security engineer, cleared system administrator, and any DoD contractor role that mentions RMF or STIGs.

Security Technical Implementation Guides are the DoD configuration standards for operating systems, applications, and network devices, and they are public. Download the STIG for Windows 11 or Red Hat Enterprise Linux (or a free rebuild of it), open it in the free STIG Viewer, and work through it against a fresh VM.

• Run the automated benchmark first (SCAP Compliance Checker or a comparable tool) to get a baseline pass/fail count. Screenshot it.
• Manually remediate the CAT I findings and a reasonable sample of CAT II findings. Document each change and the rule ID it satisfies.
• Rerun the benchmark. Screenshot the new count.
• Write a short summary: starting compliance percentage, ending percentage, the rules you deliberately did not apply and why (some STIG rules break functionality in a lab, and saying so is a feature).
• Save the completed checklist file. That file is your artifact.

The ISSO STIG checklist walks through how this is done on real systems. The interview payoff for DoD contractor roles is enormous: when a hiring manager asks “have you worked with STIGs,” you are the one entry-level candidate who can open a checklist and talk about a rule you argued with. I have watched that single project move a candidate from “maybe” to “offer.”

Project 4: an incident response tabletop you designed

Maps to: incident response, SOC, GRC, ISSO, and security awareness roles. Also the cheapest project on this list: it needs a document, not a lab.

A tabletop exercise is a discussion-based walkthrough of an incident scenario. Real organizations are required to run them (IR-3 in NIST 800-53 requires incident response testing), and they are chronically under-prepared, which makes someone who has actually written one unusually valuable.

• Pick a realistic scenario: a phishing email leads to credential theft leads to unauthorized access to a file share. Keep it boring; boring is realistic.
• Write the scenario in three or four “injects” (new information revealed over time), each with discussion questions for the participants.
• Define the roles at the table: incident commander, SOC analyst, system owner, communications, legal. Write what each should be deciding at each inject.
• Map the exercise to a framework: the NIST 800-61 incident phases, and the DoD reporting timelines if you are targeting federal work.
• Run it. With friends, a study group, a Discord server, anyone. Then write an after-action report: what went well, what gaps surfaced, three recommended improvements.

The after-action report is the artifact. The interview payoff: behavioral questions about “a time you handled pressure” or “how would you respond to a breach” get answered with a structured exercise you built and facilitated, which sounds like a professional and not like a student.

Project 5: a GRC control mapping

Maps to: GRC analyst, compliance analyst, IT auditor, ISSO, and third-party risk roles. The project people skip because it is not technical, and the one that makes GRC hiring managers sit up.

Take a real system you control (your home lab, a small business network you have permission to document, or a fictional but fully specified small system) and map it to a control framework. For DoD and federal targets, use NIST 800-53 Rev 5. For commercial targets, use the CIS Controls or NIST CSF.

• Write a one-page system description: purpose, users, data types, components, boundary. This is the first section of a System Security Plan and almost nobody entry-level has written one.
• Pick ten to fifteen controls across at least four families (access control, configuration management, audit, incident response, contingency planning are good choices).
• For each control, write an implementation statement: how this system meets the control, in plain English, with a reference to evidence. Where the system does not meet it, say so and write a planned remediation.
• Produce a status table: implemented, partially implemented, planned, not applicable, with a one-line justification for each “not applicable.”

The interview payoff: GRC interviews are dominated by “how would you document this” and “what evidence would you ask for.” You will have done both, on paper, for a system you can describe from memory. For ISSO roles specifically, you have just demonstrated the core of the job before day one.

How to present the portfolio

A portfolio nobody can find is a diary. Presentation rules:

• One public home. A GitHub repository with a clear README, or a simple personal site. One link, placed on the resume under your name and on your LinkedIn profile.
• One page per project. Title, what it maps to, what you built, what you learned, what you would do differently, and a link to the full report. Sanitize anything that looks like a real internal hostname or IP range if you documented a system you did not fully own.
• Lead with the report, not the code. Hiring managers read documents faster than repositories. Put the PDF or markdown writeup first.
• Put the projects on the resume. A “Projects” section with one line each, written like a job bullet: what you did, with what tool, producing what result. “Built a Wazuh SIEM with custom Sysmon detections for credential-theft behavior; documented detection logic and tuning” is a resume line.
• Rehearse the three-minute version. For each project, be able to explain it in three minutes to a non-technical recruiter and in ten minutes to a technical panel. Practice out loud. The project you cannot explain is worth nothing.

Which projects for which target

• SOC or security operations: projects 1 and 4, then 2.
• GRC or compliance: projects 5 and 4, then 2.
• ISSO or DoD contractor: projects 2, 3, and 5. That trio covers vulnerability management, STIG compliance, and RMF documentation, which is the job.
• Systems or cloud security: projects 3 and 2, then rebuild project 1 in a free cloud tier.
• Not sure yet: project 2. It touches every lane and it is the fastest to finish.

Two or three well-documented projects beat five thin ones. Pick the two that match your target, finish them completely, write them up properly, and then apply. The 6-month plan for a cybersecurity job with no experience shows where these projects sit in the overall timeline.

If you want the project templates, the report outlines, and the resume lines for each of these five written out and sequenced with the certification study, that is inside Zero to Hired, and it is the same material I would hand a career changer who asked me where to start.