🔄 Topic

I prepared a simulated vulnerability-assessment report for a scenario involving a business-critical database exposed to the public internet. The valuable lesson was not a magic number in a risk table. It was learning to define scope, state limitations, and keep an assessment from pretending to be a scan, a log review, or a penetration test.

🎯 Goal

Practice a transparent qualitative risk assessment using the structure of NIST SP 800-30 Rev. 1, then turn the identified risks into realistic preventive, detective, and recovery-oriented controls.

🛠 What I Did

The scenario used a Linux-hosted MySQL database that remote staff depend on for operational and customer information. I treated it as a simulated training assessment; I did not scan, probe, exploit, or access a live system.

I scoped the analysis around confidentiality, integrity, and availability risks created by direct public exposure. I assessed three plausible threat events:

  • unauthorized data access or exfiltration
  • unauthorized alteration or deletion through an insider or compromised account
  • denial of service affecting staff access to the database

I used qualitative likelihood and severity values to prioritize the risks. The numbers are decision aids based on the scenario assumptions, not measurements from a vulnerability scanner. The report explicitly records that limitation so a reader knows what the assessment can and cannot prove.

🔗 Key Cybersecurity Connections

The risk assessment linked several controls into one defensible remediation direction:

  • remove direct public database exposure and require a private remote-access path
  • use MFA and role-based permissions for administrative and data access
  • protect data in transit and apply patches promptly
  • centralize authentication, privileged-action, operating-system, and remote-access telemetry
  • maintain tested backups and recovery procedures for integrity and availability failures

This is defense in depth expressed as a decision: no one control makes a public-facing database safe. Network exposure, identity, authorization, data protection, monitoring, and recovery each address a different part of the risk.

🔍 Investigation Questions

  • Is the service actually reachable directly from untrusted networks?
  • Which users, applications, and remote paths legitimately need database access?
  • Are privileged database actions attributable to individual identities?
  • What evidence exists for large exports, unusual result sets, failed logins, or suspicious connection rates?
  • Can the organization restore correct data after an unauthorized change or destructive event?
  • Which conclusions are supported by configuration, logs, or testing, and which remain assumptions pending validation?

🚨 Detection Opportunities

The assessment produced clear monitoring ideas:

  • unexpected database exposure from untrusted source networks
  • repeated authentication failures or a sudden new administrator identity
  • unusually large query results or export-like activity
  • uncommon privileged UPDATE or DELETE behavior
  • connection-rate spikes, resource saturation, or service-health failures
  • missing or failed backup and recovery checks

Example detection hypothesis:

asset=business_database
signal=large_result_set_followed_by_unusual_network_egress
risk_area=possible_data_exfiltration
triage=validate_user_role_query_context_and_network_destination

🧭 MITRE ATT&CK Techniques

The assessment is not evidence that a technique occurred. If supporting telemetry later showed the behavior, relevant investigation could include:

  • T1078 — Valid Accounts
  • T1213 — Data from Information Repositories
  • T1486 — Data Encrypted for Impact
  • T1499 — Endpoint Denial of Service

Technique labels should follow observed evidence, not the mere existence of a risk register.

🗺 Visual Investigation Diagram

Define asset and business dependency
    ↓
Set scope, assumptions, and limitations
    ↓
Identify plausible threat events
    ↓
Assess likelihood × severity qualitatively
    ↓
Prioritize controls and telemetry
    ↓
Validate later with configuration review, logs, scanning, and authorized testing

⚠ Challenges

The challenge was being precise about the word “assessment.” It is easy to write as if a risk table proves that an exposed service is exploitable. It does not. A qualitative assessment identifies and prioritizes plausible risks; a scan, configuration review, log investigation, and authorized penetration test answer different questions and need their own evidence.

📚 What I Learned

I learned that a useful assessment is honest about its evidence boundary. Stating the scope and limitations does not weaken the report. It makes the recommendations more credible because stakeholders can see what was reasoned from the scenario and what still needs technical validation.

➡ Next Steps

  • Practice turning a qualitative finding into a testable verification plan
  • Learn how to interpret vulnerability-scan results without confusing them with exploitation evidence
  • Compare preventive controls with the telemetry needed to verify that they work
  • Revisit NIST SP 800-30 concepts when building future risk registers

🧠 Reflection

The most practical takeaway was that risk scoring should lead to a better next question, not end the investigation. A high score tells me where to look first; it does not replace checking the actual network path, configuration, logs, and recovery capability.

🧩 Lessons Learned

What worked

Keeping the asset, scope, threat event, risk rationale, recommendation, and evidence limitation visible in the same assessment.

What could go wrong

Calling a simulated qualitative assessment a vulnerability scan or presenting risk scores as if they were live technical findings.

Takeaway

Use risk scores to prioritize work, then validate the priority with the right technical evidence.

📈 Skill Progression Context

This supports my cybersecurity progression because risk assessment is how technical observations become defensible security decisions. It helps me connect a database exposure, an identity-control gap, or a recovery weakness to business impact without overstating what the available evidence proves.

😄 TL;DR

A risk score helps decide what to investigate first. It is not a substitute for the scan, logs, configuration review, or authorized test that can prove what is actually happening.