Ravindra BagaleCourses & study guides मराठी Track your progress

20. Vulnerability Scanning and Assessment

20.6 Reading Results: False Positives and Prioritising

By Last updated:

Scanner ne 200 findings dile mhanje 200 problems nahit. Ethical hacker cha khara kaam mhanje kharya dhokyanchi nivad karne.

Term Meaning Example
True positive Scanner says vulnerable, and it really is vsftpd 2.3.4 backdoor confirmed
False positive Scanner says vulnerable, but it is not Version guessed wrongly from a banner; the package was patched
False negative Real vulnerability the scanner missed A logic flaw in your own PHP code
True negative Not vulnerable, and scanner agrees –

How to confirm a finding: check the exact installed version on the server (rpm -q httpd on Amazon Linux, dpkg -l | grep apache2 on Ubuntu), read the vendor advisory, reproduce the check safely in the lab, and look for evidence (a response, a file, a banner) you can screenshot.

How to prioritise – not just by CVSS score:

  1. Critical/High and reachable from the internet – fix first (for example an open database port with a known remote bug).
  2. Known to be exploited in the wild – CISA publishes a "Known Exploited Vulnerabilities" catalog; anything listed there jumps the queue.
  3. Easy to exploit – a public exploit exists and no login is needed.
  4. Business impact – the server holding customer data matters more than a test box.
  5. Medium/Low – fix in the normal patch cycle.

Ravindra Bagale's Tip

Copy-pasting the scanner output into the report is the biggest mistake. The client doesn't want 300 pages; they want "fix these 5 first". Remove false positives, confirm findings and set priorities – that is what we call an assessment, not just a scan.

Practice task

From your Greenbone report, choose five High or Critical findings. For each, write whether it is a true or false positive and how you confirmed it, then rank them 1–5 using the list above with one line explaining each rank.

A simple priority method

When a scanner returns hundreds of lines, use this order:

  1. Anything on CISA KEV or actively exploited → today.
  2. Critical/High with a fix available on internet-facing hosts → this week.
  3. Internal hosts → scheduled maintenance.
  4. Informational findings → backlog or accept with a written reason.

Example (sample data)

Suppose we are at a Flipkart-style team. Scan results: 3 critical, 40 medium, 120 low. One critical is Log4j on an internet-facing Java service (KEV). That ticket is P1. A medium about a missing cookie flag on an internal admin tool is P3.

False positives

Banner-based version guesses are often wrong after backports. On Ubuntu and Amazon Linux, always confirm with the package manager before declaring a host vulnerable.

Recap

  • Prioritise by exposure and exploitability, not by raw count.
  • Confirm before you panic.

Defender's worksheet (do this today)

  1. Write the lesson title and date in your notebook.
  2. List three systems you own (VMs, personal projects, or lab apps) where this lesson applies.
  3. Run one safe command or checklist item from the lesson on a lab system only.
  4. Paste the command and its output under an Evidence heading.
  5. Write one fix you would give a teammate in two sentences.
  6. Write one mistake students make with this topic and how to avoid it.

More real-world pictures

Indian workplace (sample data)

Suppose we are a junior analyst at Tech Mahindra supporting a client SOC. After reading this lesson you add one detection or one hardening item to the team weekly checklist, with the owner name and a due date. That is how learning becomes operations.

Global practice

Public bodies such as CERT-In (India), CISA (US) and NCSC (UK) publish advisories that map to the same ideas: patch, least privilege, logging and user awareness. Bookmark one advisory feed and read it every Monday.

Home and family

Explain this lesson to a family member in four sentences without jargon. If they can repeat the main warning back to you, you understand it well enough to teach.

Connect to earlier chapters

Parts 1 to 9 built Linux, web servers, databases and cloud pieces. This lesson only makes sense when you can point to a concrete config file, package name or architecture box from those parts. If you cannot, revisit the matching earlier chapter before you practise any tool command.

Common mistakes

  • Skipping written permission just for a quick scan.
  • Practising on hostel or office Wi-Fi targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying exploit commands onto production to verify. Verification for defenders means checking versions and patches, not firing modules.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Teach one other person the warning from this lesson.