Lab 2 of 17 · By Michael Stout
In this lab
Read the steps, then try them in your lab environment.
Score a risk with NIST SP 800-30
Chapter 1 teaches you to identify threats and vulnerabilities and weigh them into a risk rating. This lab runs that through NIST's own four-step model, against one realistic scenario, so you leave with a repeatable method instead of a gut call.
A repeatable method beats a gut call
Two analysts looking at the same exposed server often disagree on how bad it is — not because one is wrong, but because they're weighing different things. A shared process forces the same questions onto the table every time: what's the threat, what's the vulnerability, how likely, how bad. SP 800-30 is that process, written down. It's the model behind “Determine Likelihood, Impact, and Risk” in Chapter 1, and the one most private-sector risk registers borrow from even though it was written for federal systems.
SP 800-30 Rev. 1 only binds federal agencies. Nobody will audit you against it directly — but CompTIA expects you to know its structure, and most vendor risk frameworks quietly reuse it.
What you'll need
Nothing to install. Optionally keep csrc.nist.gov/pubs/sp/800/30/r1/final open in a tab while you work.
Pen and paper, or a blank spreadsheet — you're filling in a worksheet, not running software.
30–45 minutes for the scenario on page 2, longer if you also score the three on page 2's “examples to try.”
There's no single correct score. The point is showing your reasoning, the same way an exam scenario question expects you to.
Prepare, conduct, communicate, maintain
- Prepare. Before you name a single threat, set the frame: what's the purpose and scope of this assessment, what are you assuming, and what's the organization's actual tolerance for risk? Skipping this is why two analysts land on different numbers.
- Conduct. Identify the threat source and the threat event it could initiate; identify the vulnerability and any predisposing condition that makes it worse; determine likelihood; determine impact (magnitude); combine likelihood and impact into a risk rating.
- Communicate. A risk assessment that stays in your notebook didn't happen. Share the finding with whoever owns the budget to fix it — not just whoever owns the server.
- Maintain. Risk ratings go stale. Revisit on a schedule, or the moment something material changes — a patch, a new control, a new exposure.
Score this, then score your own
Your organization runs a customer database on an internet-facing Windows Server 2016 box, three patch cycles behind. It holds names, emails, and hashed passwords for 40,000 customers. No WAF sits in front of it. Two administrators share a local admin password that hasn't been rotated in three years.
Who or what would go after this? (Consider both an opportunistic scanner and a targeted actor.)
What would they actually do to it?
What specifically makes the threat event possible here?
Low, medium, or high — and why?
Low, medium, or high — and why?
Combine the two. Would you report this up today, or log it for next quarter?
Without your organization's actual risk tolerance and asset value, no score here is “the” right answer — and that's fine. What Chapter 1 is testing, on the exam and on the job, is whether you can work the method, not whether you guess the grader's number.
Three more assets worth scoring
- A personal phone with no MDM used to read the CEO's work email over the hotel Wi-Fi on a business trip.
- A cloud storage bucket set to public-read six months ago for a one-off file share, and never set back.
- A vendor with standing VPN access from a contract that ended four months ago, with no offboarding ticket ever filed.
Sources. National Institute of Standards and Technology, SP 800-30 Rev. 1: Guide for Conducting Risk Assessments, csrc.nist.gov/pubs/sp/800/30/r1/final. The scenario and “examples to try” on this page are original teaching material, not drawn from the standard.