Findings
Northbay Regional Health16 findings, ordered by the Aegis priority model. Expand any item to see the CISO judgment behind its rank.
CriticalAEG-0001S3 bucket with PHI exports readable by any authenticated AWS principal
AWSPR.DS-1
S3 bucket with PHI exports readable by any authenticated AWS principal
This jumps to the top of the queue not just for severity but because it is exploitable with a single stolen key and directly triggers breach-notification law — regulatory exposure, not CVSS, sets the priority.
A misconfigured bucket holding patient record exports is one leaked credential away from a reportable HIPAA breach, HHS OCR penalties, and mandatory patient notification for a regional hospital.
Bucket 'nbrh-clinical-exports' has a policy granting s3:GetObject to arn:aws:iam::*:root (any AWS account), and objects are unencrypted at rest (no SSE-KMS).
Remove the cross-account/authenticated-principal grant, enforce a bucket policy denying non-TLS access, and enable SSE-KMS with a dedicated CMK. Confirm no external access via Access Analyzer.
CriticalAEG-0002In progressRoot and admin AWS accounts without MFA
AWSPR.AC-1
Root and admin AWS accounts without MFA
Rated critical despite being 'just an identity setting' because it compounds every other AWS finding — unremediated MFA turns a medium misconfig into a full-estate compromise.
The keys to the entire hospital cloud estate — including every PHI store — are protected only by a password, meaning one phishing hit could hand an attacker total control.
AWS root user has MFA disabled and 3 IAM users in the 'Administrators' group have no MFA device registered; two have active access keys.
Enforce hardware/virtual MFA on root and all admin users via SCP, rotate the exposed admin access keys, and move to federated Okta SSO with no standing IAM users.
HighAEG-0007Publicly shared Google Drive files containing patient information
Google WorkspacePR.DS-1
Publicly shared Google Drive files containing patient information
I prioritize the four files owned by former employees first — data that leaves with people who no longer answer to us is the least controllable and most likely to surface later.
Spreadsheets with patient names and appointment details are shared as 'anyone with the link,' an unmonitored leak path that would count as an impermissible HIPAA disclosure.
DLP scan found 11 Drive files shared link-anyone that match PHI patterns (MRN, DOB, patient name columns), 4 owned by former employees.
Revoke link-anyone sharing on flagged files, enable a Workspace DLP rule blocking external sharing of PHI patterns, and reassign orphaned files.
HighAEG-0008Okta admin roles granted without step-up MFA policy
OktaPR.AC-7
Okta admin roles granted without step-up MFA policy
Identity provider admins are the crown jewels of a modern estate — I hold them to a stricter bar than production systems, because compromising them compromises everything downstream at once.
Okta is the front door to every connected system; weak controls on its administrators mean a single compromised admin can unlock the entire environment, including PHI.
9 users hold Okta Super/Org Admin roles but the admin console sign-on policy does not require phishing-resistant factors; SMS is still an allowed factor.
Enforce FIDO2/WebAuthn for all admin roles, disable SMS as a factor for privileged access, and reduce Super Admin count to the minimum needed.
HighAEG-0005RDS instance hosting EHR data is publicly accessible
AWSPR.DS-2
RDS instance hosting EHR data is publicly accessible
Public + PHI is a combination I never leave open past the day I find it; exposure over the internet moves this ahead of internal-only misconfigs regardless of matching severity scores.
A database backing electronic health records is reachable from the open internet, dramatically widening the attack surface for the most sensitive data the hospital holds.
RDS PostgreSQL instance 'nbrh-ehr-prod' has PubliclyAccessible=true and a security group allowing 5432 from 0.0.0.0/0.
Set PubliclyAccessible=false, restrict the security group to the application subnet, and place the instance behind a private endpoint only.
HighAEG-0006In progressHardcoded API secret committed to internal GitHub repo
GitHubPR.DS-5
Hardcoded API secret committed to internal GitHub repo
Secrets in git are treated as already-compromised — rotation urgency is driven by the assumption of exposure, not by whether we can prove someone read it.
A live credential sitting in source code means anyone with repo access — including a departing engineer or a compromised laptop — can quietly reach connected systems.
Repo 'nbrh-integrations' contains a committed Twilio auth token and a plaintext database connection string in config/prod.env across 40+ commits of history.
Revoke and rotate the exposed secrets immediately, purge them from git history, enable push protection / secret scanning, and move secrets to AWS Secrets Manager.
HighAEG-0003CloudTrail logging disabled in two active regions
AWSDE.CM-1
CloudTrail logging disabled in two active regions
Detection gaps rank above many higher-CVSS config issues because a CISO knows the post-breach question is always 'what did they take?' — no logs means you must assume the worst and notify everyone.
If a breach involving patient data occurs in these regions, the organization cannot prove scope or timeline to regulators, converting a contained incident into a worst-case 'assume-all-PHI-exposed' disclosure.
CloudTrail is not enabled in us-west-1 and us-east-2, both of which contain running EC2 and RDS instances; no organization-wide trail is configured.
Deploy an organization-level, multi-region CloudTrail to a locked, log-validated S3 bucket with CloudTrail Lake retention meeting the 6-year HIPAA documentation window.
HighAEG-0004IAM access keys older than 400 days still active
AWSPR.AC-1
IAM access keys older than 400 days still active
I weight this higher than its severity label because these keys have broad data-plane access — a stale key on a read-only role is noise, a stale key on the PHI database is a fire.
Long-lived static credentials are the most commonly abused foothold in cloud breaches; each stale key is an unmonitored door into systems that touch patient data.
6 IAM access keys exceed 400 days without rotation, including 2 tied to service accounts with s3 and rds permissions.
Rotate or delete all keys older than 90 days, migrate service workloads to IAM roles/IRSA, and enforce a max-key-age guardrail.
MediumAEG-0009Dormant Okta accounts for terminated staff still active
OktaID.AM-6
Dormant Okta accounts for terminated staff still active
The five with live clinical-app assignments get handled immediately; the rest are cleanup — same finding, but the ones still touching patient apps are the real risk.
Accounts belonging to people who have left the organization remain live, creating unaccountable access that fails both HIPAA access-management and SOC 2 offboarding expectations.
23 Okta accounts show no login in 90+ days, 14 of which map to HR-confirmed terminations; 5 retain application assignments to clinical apps.
Deactivate confirmed-terminated accounts today, and wire Okta lifecycle deprovisioning to the HRIS to make offboarding automatic.
MediumAEG-0012GitHub organization lacks branch protection and required reviews
GitHubPR.IP-3
GitHub organization lacks branch protection and required reviews
I care most about the handful of repos that deploy to patient-facing systems; branch protection on a dead internal tool is checkbox work.
Without code review gates, a single account (or a rushed developer) can push unvetted code straight to production systems that handle patient data.
12 of 18 repos have no branch protection on the default branch; force-push and direct commits to main are permitted org-wide.
Enable required PR reviews, status checks, and no-force-push on default branches for all repos handling production or PHI-adjacent code.
MediumAEG-0014No documented, tested incident response runbook for cloud breaches
AWSRS.RP-1
No documented, tested incident response runbook for cloud breaches
Process gaps don't show up on a scanner, but this is where a manageable incident becomes a board-level crisis — I insist on it even though nothing here is technically 'broken.'
When a PHI incident hits, the 60-day HIPAA breach-notification clock starts immediately; a team improvising its response risks missing legal deadlines and compounding the damage.
No current IR plan covers cloud-specific scenarios (key compromise, S3 exposure) and no tabletop exercise has been run in the last 12 months.
Adopt a cloud IR runbook mapped to the HIPAA notification timeline, assign roles, and run a tabletop this quarter.
MediumAEG-0011Security groups allowing unrestricted SSH/RDP from the internet
AWSPR.AC-5
Security groups allowing unrestricted SSH/RDP from the internet
Standard hygiene, but I bump the jump-host instance up the list because lateral-movement pivots matter more than isolated boxes.
Open management ports are constantly scanned and brute-forced; each one is a low-effort entry point an attacker can automate against.
4 security groups permit 22/tcp or 3389/tcp from 0.0.0.0/0, attached to 6 EC2 instances including a jump host.
Replace open management access with SSM Session Manager or a VPN-gated bastion, and scope any remaining rules to corporate IP ranges.
LowAEG-0015Overly permissive IAM policies with wildcard actions
AWSPR.AC-4
Overly permissive IAM policies with wildcard actions
Low as a class, but the CI/CD role is the exception I fix now — an over-privileged pipeline is a supply-chain incident waiting to happen.
Broad, least-privilege-violating permissions mean any single compromised role does far more damage than it should, widening the blast radius of any incident.
8 IAM policies use Action:'*' or Resource:'*' patterns, including a CI/CD role with account-wide access.
Scope policies to least privilege using Access Analyzer's generated policies, starting with the CI/CD role.
MediumAEG-0013In progressGoogle Workspace lacks enforced 2SV for all users
Google WorkspacePR.AC-1
Google Workspace lacks enforced 2SV for all users
Billing and HR accounts get the enforcement deadline first — that is where the wire-fraud and W-2 phishing money actually flows.
Email is the primary target for healthcare phishing and the entry point to most ransomware; unenforced 2-step means a large fraction of staff mailboxes rely on passwords alone.
2-Step Verification is enabled but not enforced; 187 active accounts have no second factor registered, including several in billing and HR.
Enforce 2SV org-wide with a short grace window, prioritizing billing, HR, and clinical-admin groups, and prefer security keys for high-risk roles.
MediumAEG-0010S3 bucket versioning and MFA-delete disabled on backup buckets
AWSRC.CO-1
S3 bucket versioning and MFA-delete disabled on backup buckets
Recovery findings rarely feel urgent until the day they are catastrophic — for a hospital that cannot afford downtime, I treat backup immutability as non-negotiable resilience, not a nice-to-have.
Without immutable backups, a ransomware actor could encrypt or delete the hospital's recovery data, turning a survivable incident into a prolonged outage of patient-care systems.
Backup buckets 'nbrh-db-backups' and 'nbrh-config-backups' have versioning off and no Object Lock, so a compromised key can silently overwrite backups.
Enable versioning and S3 Object Lock (compliance mode) with a defined retention, and restrict delete permissions to a break-glass role.
LowAEG-0016Password policy below NIST guidance in Okta
OktaPR.AC-1
Password policy below NIST guidance in Okta
Genuinely low once phishing-resistant MFA is in place — I'd rather the team spend effort on the admin-MFA and PHI-exposure items above than gold-plate password length.
Weak authentication baselines make credential-stuffing and guessing attacks easier across every connected app.
Okta default password policy allows 8-character minimums, no breached-password check, and no lockout threshold configured.
Raise minimum length to 12+, enable Okta's breached-password (HIBP) check, and set a sane lockout threshold.