Introduction

This risk register simulates a GRC assessment for small clinics that use OpenMRS, an open-source EMR system. It manages patient demographics, medical history, lab results, and other clinical records, deployed on-premise for enhanced control and data sovereignty, minimizing third-party risks. This setup supports a practical cybersecurity risk evaluation. The primary objectives are protecting patient privacy (PHIPA/PIPEDA compliance) and maintaining operational efficiency (revenue uptime).

Risk Context

The 2025 Verizon DBIR notes medical data, like OpenMRS’s, tops breach targets, with system intrusion as the leading cause. PHIPA imposes fine of up to $1M for organizations, underscoring breach severity. This context necessitates a simulated risk assessment.

My Approach to Risk Assessment

This is my general risk assessment approach, drawn from various frameworks, designed to adapt and evolve. I’ll enhance it with ISO and SOC comparisons in future posts [links TBD], reflecting my learning journey.

Assumptions

Assumptions reflect a typical small Canadian clinic in a suburban/rural setting (e.g., 15,000 population). Larger urban clinics (Toronto) may have more hybrid/cloud elements, which can be explored in future assessments.

Server and Database: One on-premise server housed in a locked server room, with the PostgreSQL database running on the same physical computer to simulate a basic clinic setup.

Workstations: 5 desktop workstations used by staff for data entry and administration, all located within the same clinic building.

Mobile Devices: None, to simplify the scope for this initial assessment.

Site: A single clinic site, with all assets on-premises and no multi-town or distributed locations.

Network: A local network connecting the server and workstations, with basic security (e.g., firewall, no public internet exposure for now).

Usage: The system supports patient record management, with the web interface as the primary access point.

Step 1 – Identify Assets

I began this GRC assessment by identifying assets through a systematic review of risk exposure. I analyzed OpenMRS’s Implementer Documentation, PostgreSQL setup, and Security resources to pinpoint the PostgreSQL database for patient data and the server as critical components. This process establishes the foundation for Step 2’s threat analysis.

Step 2 – Identify Threats

Next, I identified threats based on the assets using my approach. I assessed the PostgreSQL database’s data value and the server’s hosting role by reviewing Security documentation, leading to threats like system intrusion and unauthorized access. These, tailored to my system’s exposure, will inform Step 3’s likelihood assessment.

Step 3 – Determine Overall Likelihood of Threat Events

This Step 3 follows NIST SP 800-30’s three-step process for overall likelihood:

(1) Likelihood of threat event initiation/occurrence (Table G-2 and G-3- ) – how likely is an adversary to attempt the attack? (mapped to Substeps 1–2 below)

(2) Likelihood that the threat event, once initiated, results in adverse impacts (Table G-4) – how likely is success and harm given our environment? (mapped to Substeps 3–6)

(3) Overall likelihood (Table G-5) – combined score (Substep 7).

We use a 1–5 qualitative scale (1 = None, 2 = Low, 3 = Medium, 4 = High, 5 = Critical). Likelihood is estimated over the next 12 months.

Substep 1 – Define Threat-Vulnerability Context

This assessment focuses on adversarial threats (per CAPEC); non-adversarial threats (e.g., hardware failure, accidental misconfiguration by staff, or natural disaster) will be explicitly included in future expansions to demonstrate the full NIST SP 800-30 scope.

• Threat: [CAPEC-180] Exploiting Incorrectly Configured Access Control Security Levels; Vulnerability: [CWE-732] Incorrect Permission Assignment for Critical Resource; Risk: Unauthorized Access to Patient Data Due to Misconfigured Server Permissions
• Threat:[CAPEC-108] Command Line Execution through SQL Injection; Vulnerability: [CWE-89] Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’); Risk: Data Breach via SQL Injection into the OpenMRS Database
• Threat 3: [CAPEC-62] Cross Site Request Forgery; Vulnerability: [CWE-352] Cross-Site Request Forgery; Risk: Unauthorized Data Modification via CSRF attack on the OpenMRS Web Interface.

Substep 2 – Likelihood of Initiation/Occurrence

• [CAPEC-180] (Access Control Misconfiguration, CWE-732): High (4/5) – DBIR 2025: Privilege Misuse ~12% of healthcare breaches; CAPEC-180 likelihood rated High.
• [CAPEC-108] (SQL Injection, CWE-89): High (4/5) – DBIR 2025: System Intrusion ~53% of healthcare breaches; CAPEC-108 adjusted upward for high prevalence.
• [CAPEC-62] (CSRF, CWE-352): Medium (3/5) – DBIR 2025: Social Engineering ~6% of healthcare breaches; CAPEC-62 likelihood moderated by low prevalence.

Substep 3 – Assess Vulnerability Severity (Adjusted for Context)

• [CWE-732]: High (4/5) – CVE-2021-42115 (CVSS 8.1). Base severity remains high but slightly reduced by internal-only environment.
• [CWE-89]: Critical (5/5) – CVE-2021-43094 (CVSS 9.8, #3 in CWE Top 25). AV:N base score adjusted to effective AV:A due to internal network only.
• [CWE-352]: Medium (3/5) – CVE-2015-5215 (CVSS 6.1). Moderate severity unchanged.).

Substep 4 – Assess Existing Control Effectiveness

Based on basic security assumptions:

• Ineffective (4/5) for CWE-732 (default roles, no granular RBAC);
• Ineffective (4/5) for CWE-89 (no parameterized queries, no WAF);
• Neutral (3/5) for CWE-352 (basic sessions, no anti-CSRF tokens).

Substep 5 – Assess Pervasiveness of Predisposing Conditions

• CWE-732 (Incorrect Permission Assignment): High pervasiveness (4/5). Wiki-documented admin endpoints and default roles on the 5-workstation internal network create a large attack surface for privilege probes (Technical – Functional: networked multiuser; Operational – Size of population per NIST Table F-4).
• CWE-89 (SQL Injection): High pervasiveness (4/5). REST API endpoints (e.g., /ws/rest/v1/obs, /patient/search) are listed in the OpenMRS wiki and accessible from any of the 5 workstations, amplifying the chance that an internal probe discovers and exploits the lack of input filtering (Technical – Functional: networked multiuser + Technical – Security: common controls).
• CWE-352 (CSRF): Medium pervasiveness (3/5). State-changing forms are documented, but session-based privilege gating and the internal-only setup limit the number of viable attack paths (Operational – Size of population and limited external vectors).

Overall, these predisposing conditions make successful adverse impacts more likely once an attack is attempted.

Substep 6 – Assess Exploit Availability / Maturity

• CWE-732 (Incorrect Permission Assignment): Medium (3/5). Fewer turnkey exploits exist; the attack requires internal access and manual privilege probing rather than automated tools.
• CWE-89 (SQL Injection): High (4/5). Public CVEs (e.g., 2021-43094) and ready-to-use PoCs are widely available on Exploit-DB and NVD; automated SQLi tools can be used once an internal probe reaches the database endpoints.
• CWE-352 (CSRF): Medium (3/5). Fewer weaponized exploits; the attack depends on social engineering and session riding rather than direct code execution or public toolkits.

Substep 7 – Determine Overall Likelihood

We follow NIST SP 800-30’s G-5 step and combine all previous subscores using simple averaging on the 1–5 scale. The calculation is:

1. Take the score from each relevant substep (2 through 6).
2. Average them to produce the overall likelihood for that threat-vulnerability pair.
3. Map the average back to the 1–5 qualitative scale.

Calculation examples (rounded to one decimal):

• CAPEC-180 / CWE-732: (Threat Likelihood 4 + Adjusted Severity 4 + Controls 4 + Predisposing Conditions 4 + Exploit Maturity 3) ÷ 5 = 3.8 → rounds to High (4/5)
• CAPEC-108 / CWE-89: (Threat Likelihood 4 + Adjusted Severity 5 + Controls 4 + Predisposing Conditions 4 + Exploit Maturity 4) ÷ 5 = 4.2 → rounds to High (4/5) – #1 priority
• CAPEC-62 / CWE-352: (Threat Likelihood 3 + Adjusted Severity 3 + Controls 3 + Predisposing Conditions 3 + Exploit Maturity 3) ÷ 5 = 3.0 → Medium (3/5)

All likelihood scores are assessed over the next 12 months (NIST p. 10).

The next phase (Step 4 – Determine Impact and Recommend Treatment) will calculate final risk levels and propose cost-effective controls. This portfolio piece showcases my ability to translate technical vulnerabilities into business-relevant risk decisions — a core mid-level GRC skill.

Step 4 – Determine Impact and Recommend Treatment

With likelihood now established, we assess the potential impact (magnitude of harm) if the threat event succeeds. NIST SP 800-30 uses a 1–5 qualitative scale for impact (1 = Negligible, 2 = Low, 3 = Medium, 4 = High, 5 = Critical), considering effects on confidentiality, integrity, availability, regulatory compliance (PHIPA), patient safety, and financial/operational consequences for a small Canadian clinic.

Impact scores are tailored to the clinic’s context: loss of patient data could trigger fines up to $1M, loss of trust, and operational downtime estimated at $15,000–$25,000 per incident.

Impact Assessment (per Threat-Vulnerability Pair)

Impact is evaluated qualitatively across the CIA triad (Confidentiality, Integrity, Availability) on a 1–5 scale, considering PHIPA compliance, patient safety, reputation, and operational consequences for a small Canadian clinic. The overall impact score is the highest of the three CIA components (conservative approach commonly used in healthcare GRC).

CAPEC-180 / CWE-732 (Misconfigured Permissions)

Overall impact: High (4/5)

• Confidentiality: High (4/5) – Unauthorized access to patient records
• Integrity: Medium (3/5) – Possible but limited data tampering
• Availability: Low (2/5) – Minimal disruption to care

CAPEC-108 / CWE-89 (SQL Injection)

Overall impact: Critical (5/5)

• Confidentiality: Critical (5/5) – Full database breach and potential exfiltration of all patient records
• Integrity: Critical (5/5) – Data could be altered or deleted
• Availability: Medium (3/5) – Possible temporary database outage

CAPEC-62 / CWE-352 (CSRF)

Overall impact: Medium (3/5)

• Confidentiality: Low (2/5) – No direct data exposure
• Integrity: Medium (3/5) – Unauthorized modification of individual records possible
• Availability: Low (2/5) – Negligible effect on system uptime

Overall Risk Level (Likelihood × Impact)

We multiply the overall likelihood (from Step 3) by the impact score to produce a final risk level (1–25 scale, mapped to Low/Medium/High/Critical).

Risk levels are mapped using the standard 5×5 matrix commonly used in healthcare GRC: 1–5 = Low, 6–10 = Medium, 11–15 = High, 16–25 = Critical.

Likelihood × Impact	Final Risk Level
1–5	Low
6–10	Medium
11–15	High
16–25	Critical

Final Risk Scores:

• CAPEC-180 / CWE-732: Likelihood 4 × Impact 4 = 16 → High
• CAPEC-108 / CWE-89: Likelihood 4 × Impact 5 = 20 → Critical (#1)
• CAPEC-62 / CWE-352: Likelihood 3 × Impact 3 = 9 → Medium

Treatment Recommendations (NIST Risk Response Options)

We recommend the following prioritized treatments, balancing cost, effort, and business value for a small clinic:

Risk	Risk Level	Recommended Treatment	Rationale & Estimated Effort
CAPEC-108 / CWE-89 (SQL Injection)	Critical	Mitigate (immediate priority)	Implement parameterized queries and input validation across all REST endpoints. Add a lightweight WAF if budget allows. Effort: 2–4 weeks developer time. High ROI – prevents largest breach risk.
CAPEC-180 / CWE-732 (Misconfigured Permissions)	High	Mitigate	Conduct full RBAC review and implement role-based access controls with quarterly audits. Effort: 1 week + ongoing 2 hours/quarter. Essential for PHIPA compliance.
CAPEC-62 / CWE-352 (CSRF)	Medium	Mitigate (low effort)	Add anti-CSRF tokens to all state-changing forms. Effort: 1–2 days developer time. Quick win with minimal cost.

All treatments align with the clinic’s limited resources: focus first on high-impact, low-complexity fixes that protect patient data and maintain care continuity.

Business Alignment and Risk Prioritization

In a small Canadian community clinic, the top business objectives are uninterrupted patient care and full PHIPA/PIPEDA compliance. A breach could result in fines up to $1M, loss of patient trust, and operational downtime estimated at $15,000–$25,000 per incident. Therefore, risks threatening confidentiality and integrity of patient records (CWE-89 and CWE-732) are prioritized over lower-impact issues.

Conclusion

This risk assessment demonstrates a complete NIST SP 800-30-aligned process applied to a realistic small Canadian clinic using OpenMRS. By breaking down likelihood into threat initiation, adjusted vulnerability severity (including controls, exposure, and exploit maturity), and pervasiveness of predisposing conditions, we produce clear, defensible scores tied directly to PHIPA compliance and patient-care priorities.