t0ul

The Risk Rancher Field Manual: Glossary

· 10 min read · #security, #vulnerability-management, #risk-rancher, #glossary

Part of The Risk Rancher Field Manual, a hands-on guide to starting, scaling, and running a vulnerability management program.

The book defines each of these the first time it uses them. This page is for the second time, when you half remember. Grouped by theme, plain words, and where the book works each one.

The things

  • Asset. Anything you run that an attacker could reach or damage: a server, a database, an application, a cloud account, a network device. Chapter two is the list of yours. The tool calls the name of an asset its asset identifier.
  • Inventory. Chapter two’s list as a file: asset, criticality, exposure, owner, notes. The tool loads it under Configuration, Asset inventory, and scores findings against it.
  • Crown jewel. The handful of assets whose loss would end you: the customer database, the payments API, the VPN that sits on the internet. The book’s criticality scale is crown-jewel, standard, dev.
  • Estate. Everything you own, taken together. A plain word for “all your assets.”
  • Exposure. Who can reach an asset: the whole internet, only people inside your network, or nobody but a lab. The book’s scale is internet, internal, isolated.
  • Criticality. How bad it is if the asset is compromised. Set by you, per asset, in chapter two.
  • Owner. The person or team who can actually change an asset, named in chapter two. Distinct from the business owner, the person who signs for a risk on that asset in chapter eight. Sometimes the same person, often not.

The findings

  • Vulnerability. A weakness that could be used against you: a bug in a library, a bad setting, a missing patch.
  • Finding. One row a scanner or a pentester hands you: “this vulnerability, on this asset, as of this scan.” Many findings can describe one vulnerability.
  • False positive. A finding that is wrong: the scanner guessed from a version string, or flagged a test fixture. Chapter six kills two.
  • Duplicate. The same problem reported twice: by two scanners, on two scans, or as several symptoms of one cause. Chapter six merges them by the test one fix closes them all.
  • Unit of work. What is left after false positives are removed and duplicates merged: one thing to fix. The book’s count for the sample is 24.
  • Ticket. A finding written up for a human to act on: what, why, exactly what to do, by when, and who. Chapter seven’s template. In the tool every finding is a ticket from the moment it lands.
  • CVE. Common Vulnerabilities and Exposures. The public catalog of known software vulnerabilities, each with an ID like CVE-2021-44228. A CVE is the name of a vulnerability; a finding is one place it shows up.
  • CVSS. Common Vulnerability Scoring System. A 0 to 10 score of how bad a vulnerability is in the abstract, with no knowledge of where it sits in your estate. Scanners ship it. The book treats it as an input, never a priority.
  • CWE. Common Weakness Enumeration. The catalog of kinds of weakness (injection, buffer overflow) a CVE belongs to. Pentest reports cite it.
  • KEV. Known Exploited Vulnerabilities, a catalog kept by CISA (the US Cybersecurity and Infrastructure Security Agency) of CVEs that attackers are actually using in the wild. The book treats a finding on that list as a P1 whatever the arithmetic says. You download the catalog JSON from CISA’s site and load it into the tool yourself.
  • EPSS. Exploit Prediction Scoring System. A published probability that a CVE will be exploited in the next 30 days. Another threat-intelligence input, like KEV. The tool does not fetch it; you can use it in your own rubric.
  • Threat intelligence. Any outside knowledge about which vulnerabilities attackers are using. KEV and EPSS are the two free, public kinds.
  • Severity. How bad, on a scale: the scanner’s label (Critical, High, Medium, Low, Info), and in the tool, the one dial per finding that sets the clock.
  • Priority. How urgent, for you, once context is applied: P1 to P4 in the book, from the rubric in chapter six. In the tool the severity dial is the priority: P1 is Critical, P2 High, P3 Medium, P4 Low. With the inventory loaded the tool sets it at ingest; without it, you do.
  • Rubric. The book’s scoring rule: base (from scanner severity) times exposure times criticality, banded into P1 to P4, with KEV forcing P1. The tool ships with the same numbers under Configuration, Priority rubric, and you can change them.
  • Scanner severity. The scanner’s own label for a finding, which the tool keeps beside the severity it computed, so you can always see what the rubric did.
  • Rescored. The line the tool writes in a finding’s history when an inventory load, a rubric change or a catalog load moved its severity.

The finding tools

  • Scanner. Software that looks for known vulnerabilities and hands you findings. There are kinds, by what they look at, and chapter four sorts them. Network scanners probe hosts and ports. DAST, dynamic application security testing, pokes a running web application from the outside. SAST, static application security testing, reads source code. SCA, software composition analysis, checks the libraries your code pulls in. CSPM, cloud security posture management, checks cloud account settings. Container image scanners check what is packaged into an image. The book’s sample uses Nessus (network), OWASP ZAP (DAST), Semgrep and SonarQube (SAST), Trivy (container and SCA) and Prowler (CSPM). The tool’s built-in Trivy adapter names the vulnerable library as the asset and the CVE as the title, which groups an image scan by library; for an image-by-image view, build your own adapter as chapter ten shows.
  • Export. The file a scanner writes out: CSV or JSON. The raw material of chapter six.
  • Credentialed scan. A scan that logs in to the host, so it sees installed versions instead of guessing from the outside. Far fewer false positives.
  • Zero-day. A vulnerability that is being exploited before the vendor has a fix, so there is no patch to apply yet. Rare, loud, and almost never the thing that gets you.
  • RCE. Remote code execution: a flaw that lets an attacker run their own program on your system from a distance. The worst kind.
  • Pentest. A penetration test: a person, not a scanner, trying to break into one target for a fixed time, then writing a report. Chapter five. A pentester or Bounty Hunter (the tool’s role name) does it; a red team does the same across a whole organisation with stealth, which is a different, later exercise.
  • CI. Continuous Integration: the automated build that runs when developers change code. A scanner “wired into CI” runs on every change.
  • API. Application Programming Interface: the way one program talks to another without a screen. A scanner with an API can be pulled from by a script; the tool’s API is how a pipeline pushes findings in.
  • Adapter. In the tool, the saved map from a scanner’s column names to the five the tool keeps: title, asset, severity, description, remediation. Built once per scanner.
  • Ingest. To take an export in: the tool reads the file, deduplicates, and makes tickets.
  • Endpoint. One address the tool answers at, such as /api/ingest/csv. An API key is a secret string a script sends instead of a login, minted by the Sheriff; it acts as the person who minted it.
  • JSON. A plain-text format programs use to hand data to each other; most scanners can export it. The CISA catalog is one JSON file.
  • Jira. The ticket system many engineering teams live in. The book’s ticket template fits any such system, or a text file.

The work

  • Triage. Sorting: deciding which findings are real, which are duplicates, and how urgent each is. Chapter six.
  • Remediation. Fixing. Chapter seven. Mean Time to Remediate (MTTR) is the average days from found to fixed.
  • Verify. Checking that a fix worked, with a re-scan or a re-test, before calling anything closed. Chapter seven’s most skipped step.
  • Re-scan. Running the scanner again. The tool uses the next scan to close findings that are gone and reopen ones that are back.
  • SLA. Service Level Agreement: a promised deadline. In this book, the number of days a priority gives the owner to fix: P1 3, P2 14, P3 30, P4 90. The clock is the countdown to that deadline. A breach is missing it; elsewhere in security the same word means an attacker got in, and chapter two uses it that way once. Adherence is the share of findings fixed inside their SLA.
  • Exception. A written decision not to fix something, signed by the business owner, with a reason, a compensating control and an expiry. Chapter eight. The tool’s state for it is Risk Accepted.
  • Extension. More time on the clock, dated and acknowledged, for a fix that is coming late. Chapter eight.
  • Compensating control. Something you put in place to reduce a risk you are not fixing: a firewall rule, a VLAN that walls the box off, an alert. The thing that makes an exception defensible.
  • Risk acceptance. The act of signing an exception: the business owner, not security, agrees to carry the risk.
  • Audit log. The tool’s append-only record of who did what and when. Every change, every refusal and every sign-in lands in it, by the person who did it; successful reads do not.
  • Suppression rule. The tool’s memory of a false-positive decision: the same finding on later scans lands already closed.
  • Routing rule. The tool’s rule that hands every finding on an asset, or from a scanner, to a named owner as it arrives.
  • Severity rule. The tool’s rule that rewrites the severity of everything from a scanner or on an asset. “Everything on the isolated lab is Low.”
  • Air-gapped. Not connected to the internet. The tool makes no network calls at all, so it can run where nothing is allowed to phone home.

The tool’s names

  • States. Waiting to be Triaged, Triaged, Assigned Out, Returned to Security, Pending Verification, Pending Risk Approval, Patched, Risk Accepted, False Positive. Chapter nine has the table.
  • Tabs. Holding Pen (new and returned findings), The Chute (assigned out), Pending Verification, The Archives (closed). Risk Reviews is in the Sheriff’s office, under Admin.
  • Roles. Sheriff (admin), RangeHand (analyst), Wrangler (owner), Magistrate (approver), Bounty Hunter (pentester).
  • Links. /share/<token> is the owner’s inbox; /review/<token> is the approver’s desk. No account needed for either.
  • Domain. The tool keeps a separate SLA matrix per kind of work: Vulnerability, Privacy, Compliance, Incident. This book only uses Vulnerability.
  • Magic link. The industry name for a link that stands in for a login. The book just says link. The random string at the end is the token; a batch is the set of findings one link covers.
  • Drawer. The panel that slides open when you click a finding on the dashboard: its text, its history, and the fields you can edit.
  • Engagement. A pentester’s unit of work in the tool: one test, its findings, and the report that comes out of it.
  • Copy Batch Link. The button on Risk Reviews that mints the approver’s link for a group of requests.

The command line

The exercises use a handful of programs that are on most machines or one install away. None is required to read the book.

  • python3 runs score.py, metrics.py and make-million.py. Run each from the folder you downloaded it to.
  • git fetches the tool’s source; go builds it. Both are one download from their sites.
  • curl sends a request to a URL from the command line; the book uses it to show what a click does.
  • sqlite3 opens the tool’s database file (data/riskrancher.db) so you can count rows yourself. It is optional; the screens show the same numbers.
  • trivy and docker are only for chapter four’s optional exercise: Trivy is a free scanner, and it needs a container runtime such as Docker to pull the image it scans.

← Back to the blog