Summary

I completed a scenario-based vulnerability assessment for a business-critical MySQL database described as directly reachable from the public internet. The work used the qualitative structure of NIST SP 800-30 Rev. 1 to identify risks, prioritize controls, and state what further validation would be needed.

This was a training scenario. I did not scan, probe, exploit, or access a live database or production network.

Assessment Scope

The simulated system was a Linux-hosted MySQL database used by remote employees to retrieve operational and customer information. I scoped the assessment to access-control and network-exposure risks affecting confidentiality, integrity, and availability.

The stated limitation was central to the assessment: the findings are reasoned from the scenario, not derived from vulnerability scanning, configuration review, log analysis, or penetration testing. Those activities would be the next evidence-producing steps before treating a risk as a confirmed technical finding.

Risk Analysis

I prioritized three plausible threat events using qualitative likelihood and severity values:

Threat event Risk rationale Qualitative priority
Unauthorized access and data exfiltration Direct public exposure expands opportunities for reconnaissance, credential attacks, and exploitation; disclosure of customer or business data could have severe impact. High
Unauthorized alteration or deletion A malicious insider or compromised account could damage operational data and interrupt work. Medium-high
Denial of service A public-facing service can be targeted with resource exhaustion, preventing remote staff from using a business-critical system. Medium-high

The scores are decision aids, not proof that any event occurred. Their purpose is to make the next security work explicit: validate the highest-impact assumptions first.

Design Decisions

  • Keep the asset, scope, assumptions, limitations, risk rationale, and remediation strategy visible in the same report.
  • Treat direct public database reachability as an exposure requiring validation, not a finding proven by a risk score alone.
  • Recommend controls across network, identity, authorization, monitoring, and recovery layers rather than relying on a single product or configuration change.
  • Separate preventive controls from the logs and checks needed to verify that those controls are effective.

Remediation Direction

  • Remove direct internet database access and use a private remote-access path such as VPN or zero-trust network access.
  • Require MFA and least-privilege role-based access for administrative and data-access functions.
  • Keep data protected in transit, patch operating-system and database components promptly, and review database configuration.
  • Centralize authentication, privileged-action, operating-system, firewall, and remote-access logs.
  • Maintain tested backups and recovery procedures to reduce integrity and availability impact.

Monitoring and Validation Plan

The next technical validation should establish whether the database is reachable from untrusted networks and whether only approved remote paths can reach it. Relevant telemetry would include:

  • successful and failed database authentication
  • administrator and privileged-query activity
  • unusually large result sets, exports, or unexpected query volume
  • abnormal connection rates and resource saturation
  • firewall or remote-access activity associated with database connections
  • backup, restore, and service-health outcomes

An analyst should correlate these data sources before deciding whether activity is normal remote work, a misconfiguration, or suspicious access.

Security Relevance

  • Confidentiality: private access paths, strong authentication, least privilege, and database audit records reduce and expose unauthorized data access.
  • Integrity: role-based permissions, change controls, and recoverable backups reduce the impact of unauthorized modification or deletion.
  • Availability: network restrictions, connection monitoring, capacity planning, and tested recovery reduce denial-of-service and outage impact.
  • Evidence discipline: a qualitative assessment focuses investigation; it does not replace authorized technical testing.

What I Learned

The most useful result was learning to make a risk assessment honest and actionable at the same time. A high-risk scenario should lead to a focused verification plan, not an inflated claim that a live system was scanned or breached. Scope and limitations are part of the security value of the report because they show a future reader exactly what still needs to be tested.