diff --git a/.claude/scheduled_tasks.lock b/.claude/scheduled_tasks.lock new file mode 100644 index 0000000..0af4149 --- /dev/null +++ b/.claude/scheduled_tasks.lock @@ -0,0 +1 @@ +{"sessionId":"d6600899-b6a9-4073-b362-d7d5aa0dd8dd","pid":6332,"acquiredAt":1777065966112} \ No newline at end of file diff --git a/clients/cascades-tucson/PLAN-AND-QUESTIONS-2026-04-23.md b/clients/cascades-tucson/PLAN-AND-QUESTIONS-2026-04-23-archived.md similarity index 98% rename from clients/cascades-tucson/PLAN-AND-QUESTIONS-2026-04-23.md rename to clients/cascades-tucson/PLAN-AND-QUESTIONS-2026-04-23-archived.md index 158258d..6de05b6 100644 --- a/clients/cascades-tucson/PLAN-AND-QUESTIONS-2026-04-23.md +++ b/clients/cascades-tucson/PLAN-AND-QUESTIONS-2026-04-23-archived.md @@ -1,3 +1,5 @@ +> **ARCHIVED 2026-04-24.** Superseded by `PLAN-AND-QUESTIONS-2026-04-24.md`. This doc contained drift Howard pushed back on — see Part 7 of the successor doc for the honest drift log. Kept for historical reference only. **Do not execute against this doc.** + # Cascades of Tucson — Master Plan + Open Questions **Built:** 2026-04-23 by Howard diff --git a/clients/cascades-tucson/PLAN-AND-QUESTIONS-2026-04-24.md b/clients/cascades-tucson/PLAN-AND-QUESTIONS-2026-04-24.md new file mode 100644 index 0000000..0eda75d --- /dev/null +++ b/clients/cascades-tucson/PLAN-AND-QUESTIONS-2026-04-24.md @@ -0,0 +1,186 @@ +# Cascades of Tucson — Master Plan v2 (phones-first) + +**Built:** 2026-04-24 by Howard + Claude +**Supersedes:** `PLAN-AND-QUESTIONS-2026-04-23-archived.md` +**Target:** Pilot caregiver phone usable end-to-end by Monday 2026-04-27. +**Goal (Howard's exact words):** Authorized user + authorized device + authorized network → no 2FA → M365 sign-in (tied to domain account via PHS) → SSO into ALIS. + +> This plan was rewritten after catching scope drift in the 2026-04-23 version. See Part 7 for the honest drift log. The executable path is Track A; Track B runs in parallel; Track C is later phases. + +--- + +## Part 1 — Status as of 2026-04-24 + +### What's genuinely done +- **AD hygiene (G1)** — idempotent. OU=Excluded-From-Sync, 4 role accounts moved, 34 proxyAddresses populated, 16 SG-* groups created, display names normalized. `reports/2026-04-22-g1-execute.md` + `reports/2026-04-22-g1-post-verify.md` +- **M365 orphan cleanup (G2 partial)** — 7 orphan / former-employee accounts deleted; 1 Business Standard seat freed. `reports/2026-04-22-m365-orphan-deletes.md` +- **CS-SERVER preflight** — time sync, TLS 1.2, WSB installed, rebooted, post-reboot verification clean. Ready for Entra Connect. `reports/2026-04-22-cs-server-preflight-verification.md` +- **Synology discovery** — 10 shares, 35 users, 4 groups inventoried. 7 shared-credential HIPAA violations flagged. `docs/migration/synology-permission-inventory.md` +- **Intune MDM foundation** — MDMS@ service account, Apple MDM push cert, Android enrollment profile (dynamic group), Android compliance policy, config profiles, 7 required apps (incl. ALIS web app). 1 Samsung A15 enrolled compliant, 24 more in box. `PROJECT_STATE.md` +- **DMARC p=quarantine** + post-DMARC spoofing recheck clean. `reports/2026-04-21-post-dmarc-spoofing-recheck.md` +- **Staff CSV + working list** from Meredith/John. `reports/cascades-staff-2026-04-22.csv` +- **HIPAA review + risk register** drafted (with some accuracy issues flagged in Part 7). `docs/security/hipaa-review-2026-04-22.md` + +### What's in flight vs not started +- **Entra Connect install** — NOT started. Prep is green. +- **Phone rollout at scale** — NOT started. Pattern validated on 1 device. +- **Role mailbox conversions (G2 remainder)** — have delegation lists for 6/11; 5 pending Meredith. +- **CA policies** — nothing live. No Named Location yet. +- **ALIS SSO** — nothing registered. + +--- + +## Part 2 — Track A: Phone SSO Mission (pilot → caregiver rollout) + +**One sentence:** one caregiver, one phone, full end-to-end flow proven by Monday — then scale. + +### Phase 1 scope +- **1 pilot caregiver** (Howard picks — must be confirmed-spelling name + willing tester) +- **1 phone** (reuse current enrolled Phone 1 or fresh Samsung A15 from the 24 unopened) +- **Entra Connect sync scoped to `OU=Sync-Phase1-Caregivers` only** +- **PHS enabled** (Howard's decision 2026-04-24 — reverses prior "PHS deferred" call) +- **CA policy: MFA waived when user ∈ SG-Caregivers AND device compliant AND sign-in from Cascades WAN IP** +- **ALIS SSO live via OIDC App Registration** + +Nothing else in this tenant is touched. No office staff change. No password cutover for the cloud-only population (that's Track C Phase 2). + +### Gate-by-gate plan + +| Gate | Target day | What | Blocker / input | +|---|---|---|---| +| **A1** | Fri PM | Entra Connect install on CS-SERVER, staging mode, scope = `OU=Sync-Phase1-Caregivers`, PHS on | Howard at CS-SERVER console | +| **A2** | Fri–Sat | Pull Cascades WAN IP from pfSense; create Entra Named Location "Cascades Office"; create CA policy "Cascades - Phone MFA Exception" in Report-only | Q38 (WAN IP static? — discover from pfSense cfg, not Meredith) | +| **A3** | Fri–Sat | Email `support@medtelligent.com` for SSO Integrations kickoff; create App Registration "Cascades of Tucson - ALIS SSO" (single-tenant, redirect `https://cascadestucson.alisonline.com/ExternalLoginCallback`, ID tokens implicit hybrid enabled); create client secret "ALIS - Single Tenant Secret"; vault creds | Howard / portal access | +| **A4** | Sat | Pilot caregiver AD account in `OU=Sync-Phase1-Caregivers`; add to `SG-Caregivers`; assign unassigned Entra ID P2 (no new spend); verify ALIS staff profile email == Entra UPN exactly | Howard picks pilot (T0-1) | +| **A5** | Sun AM | Exit Entra Connect staging; full sync; verify pilot user appears hybrid with AD password live; CA What-If check confirms MFA bypass fires for correct conditions | A1–A4 green | +| **A6** | Sun PM | Enroll phone (QR from `CSC - Android Shared Phones` profile); pilot caregiver signs in via MSDM; verify zero MFA prompt on Cascades Wi-Fi; verify Teams/Authenticator/ALIS web app all SSO; verify sign-out / second sign-in works (shared-device proof) | A5 green | +| **A7** | Mon AM | CA Report-only logs reviewed (zero unexpected blocks); flip policy to On | A6 green | + +### Phase 1a (post-Monday): expand to full caregiver roster +- Create remaining ~36 caregiver AD accounts in same OU +- Purchase Business Premium seats (Q21 — tenant-wide preferred) +- Add to `SG-Caregivers` +- Factory-reset and enroll remaining 24 phones +- **Blocker resolved before 1a:** Q1 Ederick spelling + +### Track A blockers +- **T0-1 (Howard):** pick pilot caregiver — name + consent +- **T0-2 (Howard — discoverable):** pfSense WAN IP — confirm static by inspecting Cox circuit config. If dynamic, plan Named Location update hook. +- **T0-3 (Meredith, cheap ask):** sign Microsoft HIPAA BAA. Doesn't block phones technically — Meredith's covered entity exposure is the driver. 5 min. +- **T0-4 (ALIS, lead time):** ALIS Integrations team response to `support@medtelligent.com`. Send Friday. They may need 24–48h. + +--- + +## Part 3 — Track B: HIPAA Baseline (parallel to A, sized realistically) + +**Scope:** compliant-enough-to-survive-an-audit. Not gold-standard. Each item sized honestly. + +| ID | Item | Rule | Who | Effort | Cost | +|---|---|---|---|---|---| +| **B1** | Microsoft HIPAA BAA sign | §164.308(b)(1) Required | Meredith | 5 min portal click | $0 | +| **B2** | ALIS BAA confirmed | §164.308(b)(1) Required | Meredith → ALIS support | 1 email, 1–2wk vendor turnaround | $0 | +| **B3** | Risk Analysis document | §164.308(a)(1)(ii)(A) Required | Howard drafts → Mike/Howard sign Security Official → Meredith counter-signs CE | 3–4h | $0 | +| **B4** | Termination Procedures documented | §164.308(a)(3)(ii)(C) Required | Howard drafts from existing process | 1–2h | $0 | +| **B5** | Audit log retention decision | §164.312(b) + §164.316(b)(2) | Meredith picks option; Howard implements | 1h | $0 (option b) or ~$3/user/mo (option a) | +| **B6** | Synology shared-login risk acceptance | §164.312(a)(2)(i) interim | Meredith signs paper acknowledgment until Phase 4 cutover | Howard drafts form + route | $0 | +| **B7** | Break-glass admin **DECISION** (not the injected YubiKey spec — a decision entry only) | §164.312(a)(2)(ii) Addressable | Howard writes decision entry | 30 min | $0 | +| **B8** | Security Rule Implementation Register | §164.316(b) | Howard drafts — single doc listing every Addressable spec + decision | 2h | $0 | + +### Audit retention options (B5) +- **(a)** Microsoft Purview Audit (Premium) add-on — 10yr retention — ~$3/user/mo +- **(b)** M365 Compliance retention policy at 7 years — $0 *if we're on Business Premium tenant-wide* (which we would be for Phase 1a anyway) +- **(c)** Monthly export to immutable Azure Blob — $0 but operational burden + +**Recommended: (b)**, stacked on the Business Premium tenant-wide purchase we're already teeing up for Phase 1a. No additional spend. + +### What Track B does NOT include (drift scrubbed) +- ~~FIDO2 YubiKey purchase~~ — was injected; Emergency Access Procedure is Addressable, not Required; documented decision (B7) suffices +- ~~Per-user DLP policies~~ — not in Security Rule Required set +- ~~Defender for Identity / SIEM~~ — nice-to-have, not baseline + +--- + +## Part 4 — Track C: Future phases (not this week) + +| Item | When | Blocker | +|---|---|---| +| **C1** Phase 2 sync — in-building office-PHI staff (Sharon, Allison, Alma, Kyla, etc.) | Week-2 or later | Pre-cutover AD password reset to known values; 48h user comms; scheduled maintenance window | +| **C2** Phase 3 sync — remaining staff | Week-3 or later | Same mechanics as C1, larger batch | +| **C3** G2 role mailbox conversion (6 ready, 5 pending delegations) | Any time — execute the 6 with lists we have | 5 of 11 pending Meredith answers on delegates (Q8, Q11, Q14, Q15, Q16) | +| **C4** Synology → CS-SERVER file-share migration (Phase 4) | After Phase 2/3 sync | John answers on pacs/Activities/chat/Sandra Fish shares + MainOffice group membership | +| **C5** Wave 5 hardening — BitLocker fleet, LAPS, password policy, krbtgt rotation | After Phase 4 | Previous phases complete | + +--- + +## Part 5 — Open questions (slimmed, re-tiered) + +### T0 — Blocks Monday +- **T0-1 (Howard):** Pilot caregiver — who? Must be confirmed-spelling name, willing tester. +- **T0-2 (Howard, discoverable):** pfSense WAN IP — static? Query the appliance. +- **T0-3 (Meredith, Friday ask):** sign Microsoft HIPAA BAA. +- **T0-4 (ALIS, send Friday):** kick off SSO Integrations engagement via `support@medtelligent.com`. + +### T1 — Blocks Phase 1a (full caregiver rollout, not pilot) +- **Q1** Ederick Yuzon spelling — Meredith +- **Q21** Business Premium tenant-wide vs mixed SKU — Meredith (approve PO) +- **Q48** Reliable Agency shift scheduling pattern — Meredith (determines per-person vs supervised model) + +### T2 — Track B completion (parallel) +- **Q17** MS BAA (= T0-3) +- **Q18** ALIS BAA — Meredith +- **Q19** Synology shared-login risk posture (a/b/c) — Meredith → B6 +- **Q20** Audit retention path — Meredith → B5 (recommend (b)) +- **Q25** Reliable Agency contract → workforce vs BA — Meredith +- **Q27–29** Training, sanctions, termination procedure docs — Meredith + +### T3 — Blocks Phase 2/3 + Wave 4 (later) +- **Q2** Stephanie Devin status — Meredith +- **Q3** Dax Howard identity — Meredith +- **Q4** Tamra Matthews exit date — Meredith +- **Q6–16** Role mailbox delegations — Meredith (G2 remainder) +- **Q30–35** Synology content + MainOffice group — John +- **Q36** John's email activity — John +- **Q37** Matt Brooks cross-role delegation — John +- **Q38** WAN IP stability — John (confirms T0-2) +- **Q39** Dell R610 replacement — John + +### Dropped (drift — see Part 7) +- ~~**Q23** FIDO2 security key purchase~~ +- ~~**Q24** Second break-glass holder~~ + +--- + +## Part 6 — Executable now (no client answers needed) + +| Item | Agent / effort | Blocks what | +|---|---|---| +| Draft Risk Analysis (B3) | Howard, 3–4h | Nothing — parallel to Track A | +| Draft Termination Procedures (B4) | Howard, 1–2h | Nothing | +| Draft Security Rule Implementation Register (B8) | Howard, 2h | Nothing | +| Draft Synology risk-acceptance form for Meredith's signature (B6) | Howard, 30min | Nothing | +| SMB3 encryption on `\\CS-SERVER\homes` | `Set-SmbShare -Name homes -EncryptData $true` via GuruRMM | H3 HIPAA risk | +| Create `OU=Sync-Phase1-Caregivers` on CS-SERVER | Howard, 5 min | Track A Gate A1 prep | +| ALIS App Registration in Entra (A3) | Howard, 20 min | Track A Gate A5 verify | +| Email ALIS support for SSO kickoff | Howard, 10 min | Lead-time | + +--- + +## Part 7 — Drift log (honest record) + +The 2026-04-23 master plan had four accuracy/scope problems traced to doc-generation drift. Captured here so we don't repeat: + +1. **FIDO2 / YubiKey recommendation appeared without user input.** First showed up in `docs/cloud/user-account-rollout-plan.md` line 160 (commit `c077d58` — a staff-CSV ingest session where the session log has zero FIDO2 mention). Escalated to Required HIPAA finding H2 in `docs/security/hipaa-review-2026-04-22.md` (commit `6bd4166`, auto-sync, no session log). Then to Q23–24 T1 blocker in `PLAN-AND-QUESTIONS-2026-04-23.md` asking Meredith to buy a specific YubiKey 5C NFC (~$55). **The §164.312(a)(2)(ii) citation is Addressable, not Required, and doesn't prescribe FIDO2.** Removed. + +2. **ALIS SSO marked "Optional / separate project."** Gate G8 labeled optional in the old plan. In reality ALIS SSO is the endpoint of Howard's goal. Promoted to Track A Gate A3. + +3. **PHS deferred indefinitely.** Gate G5 was labeled deferred. Howard's confirmed intent 2026-04-24 is PHS enabled so M365 password == AD password. Reversed. + +4. **SAML / Enterprise App vs OIDC / App Registration.** My old writeup described ALIS SSO as "Enterprise App with SAML/OIDC." The ALIS doc (https://support.alisonline.com/hc/en-us/articles/34831696021901) specifies **App Registration with OIDC implicit hybrid flow and a client secret.** Not SAML, not Enterprise Application. Corrected in Gate A3. + +**Anti-drift commitment going forward:** new architectural decisions must trace back to a session log or user message, not be drafted unilaterally during document generation. When a document auto-adds a technical spec that nobody discussed, that's drift — we flag it rather than carrying it forward. + +--- + +## Revision history +- 2026-04-23 — original plan drafted by Howard (now archived) +- 2026-04-24 — rewritten: Track A/B/C split, phased Entra Connect sync, drift log added, Monday pilot target locked in diff --git a/clients/cascades-tucson/PROJECT_STATE.md b/clients/cascades-tucson/PROJECT_STATE.md index 8bf4998..ba67b25 100644 --- a/clients/cascades-tucson/PROJECT_STATE.md +++ b/clients/cascades-tucson/PROJECT_STATE.md @@ -10,7 +10,7 @@ | Session | Working On | Status | Started | |---------|-----------|--------|---------| -| Howard-Home/Claude (Howard) | Intune Phase B-1: Android compliance policy | IN_PROGRESS | 20:40 UTC 2026-04-21 | +| Howard-Home/Claude (Howard) | Track A phone-SSO pilot — Entra Connect prep, OU creation, WAN IP discovery, ALIS App Registration kickoff | IN_PROGRESS | 2026-04-24 (day) | **How to claim a lock:** Add a row before starting work. Remove it when done. Locks older than 2 hours with no update are considered stale. diff --git a/clients/cascades-tucson/docs/migration/phone-sso-pilot-runbook-2026-04-24.md b/clients/cascades-tucson/docs/migration/phone-sso-pilot-runbook-2026-04-24.md new file mode 100644 index 0000000..518ead8 --- /dev/null +++ b/clients/cascades-tucson/docs/migration/phone-sso-pilot-runbook-2026-04-24.md @@ -0,0 +1,361 @@ +# Phone SSO Pilot Runbook — Cascades of Tucson + +**Built:** 2026-04-24 by Howard + Claude +**Target:** Pilot caregiver phone usable end-to-end by Monday 2026-04-27 +**Reference:** `PLAN-AND-QUESTIONS-2026-04-24.md` Track A +**Pilot identity:** `howard.enos@cascadestucson.com` (AD), linked to Howard's existing ALIS admin account (`howard.enos` login) + +> This is the hands-on checklist. Each section has copy-paste-ready commands / field values. Check off as you go. + +--- + +## Pre-flight (already done) +- [x] CS-SERVER preflight green (2026-04-22 post-reboot verification) +- [x] `OU=Caregivers,OU=Departments,DC=cascades,DC=local` created 2026-04-24 +- [x] Orphan `OU=Sync-Phase1-Caregivers` removed +- [x] WAN IP discovered — primary `184.191.143.62` (confirmed, matches historical sign-in logs) +- [x] Master plan rewritten with Track A/B/C split +- [x] Risk Analysis draft saved (`docs/security/risk-analysis-2026-04.md`) + +--- + +## Gate A1 — Install Entra Connect on CS-SERVER (staging mode) + +**Prereq:** Domain admin logged into CS-SERVER console. Fresh download of Entra Connect Sync. + +Download: https://www.microsoft.com/en-us/download/details.aspx?id=47594 + +### Installer wizard — field-by-field + +| Wizard page | What to enter | +|---|---| +| Welcome | Accept license | +| Express Settings | Choose **Customize** (NOT Express) | +| Install required components | Leave defaults, Install | +| User sign-in | Select **Password Hash Synchronization**, check **Enable single sign-on** (optional — Seamless SSO for domain-joined PCs; safe to leave checked) | +| Connect to Azure AD | Sign in as Cascades tenant Global Admin (NOT the `howard.enos` test account — use your normal admin identity) | +| Connect your directories | Forest: `cascades.local`. Add with domain admin creds. | +| Azure AD sign-in configuration | Verify UPN suffix `cascadestucson.com` is verified in Azure (should be). If not, fix before proceeding. | +| Domain / OU filtering | Select **Sync selected domains and OUs**. Check **only** `OU=Caregivers,OU=Departments,DC=cascades,DC=local`. Uncheck everything else. | +| Uniquely identifying your users | Leave default: "Users are represented only once across all directories" + "objectGUID" | +| Filter users and devices | Synchronize all users and devices | +| Optional features | Leave defaults | +| **Ready to configure** | **CHECK "Enable staging mode"** — this is the key box. Install will run but NOT push anything to Azure. | +| Confirm → Install | | + +### Post-install verification (run from CS-SERVER PowerShell) + +```powershell +# Confirm staging mode is ON +Get-ADSyncScheduler | Select-Object StagingModeEnabled, SyncCycleEnabled, MaintenanceEnabled + +# Force a sync cycle (still staging — nothing pushed) +Start-ADSyncSyncCycle -PolicyType Initial + +# Check what would sync +Get-ADSyncConnector | Select-Object Name, Type + +# List staged-up users (should only include howard.enos once the account is created in A4) +Get-ADSyncCSObject -ConnectorName "cascades.local" | Select-Object DistinguishedName, ConnectorState | Select-Object -First 20 +``` + +--- + +## Gate A2 — Named Location + Conditional Access (Report-only) + +**Where:** Microsoft Entra admin center (https://entra.microsoft.com) → Protection → Conditional Access + +### A2.1 Named Location + +Entra → Protection → Conditional Access → **Named locations** → **+ IP ranges location** + +| Field | Value | +|---|---| +| Name | `Cascades Office` | +| Mark as trusted location | **Yes** (checkbox) | +| IP ranges (IPv4) | `184.191.143.62/32` | + +**Note on dual-WAN:** if pfSense query confirms a secondary WAN with a separate public IP, add that as a second `/32` entry later. Until then, we let Report-only mode show us which IPs are actually observed. + +### A2.2 CA Policy — Report-only + +Two policies implement: *"skip MFA only when SG-Caregivers member AND device compliant AND on trusted network; otherwise MFA."* + +**Policy 1: `Cascades - Caregivers - Untrusted Location - MFA + Compliant`** + +| Section | Setting | +|---|---| +| Users | Include: `SG-Caregivers` group | +| Cloud apps | Include: All cloud apps | +| Conditions → Locations | Include **Any location**, Exclude **Cascades Office** | +| Grant | **Require multi-factor authentication** AND **Require device to be marked as compliant** (select "Require all the selected controls") | +| Enable policy | **Report-only** | + +**Policy 2: `Cascades - Caregivers - Trusted Location - Non-Compliant - MFA`** + +| Section | Setting | +|---|---| +| Users | Include: `SG-Caregivers` group | +| Cloud apps | Include: All cloud apps | +| Conditions → Locations | Include **Cascades Office** only | +| Conditions → Filter for devices | Include filter: `device.isCompliant -eq False` | +| Grant | **Require multi-factor authentication** | +| Enable policy | **Report-only** | + +### A2.3 Verify via What-If tool + +Entra → CA → **What If** → simulate: +- User: `howard.enos@cascadestucson.com` +- Cloud app: Office 365 +- IP: `184.191.143.62`, location Cascades Office +- Device state: Compliant +- Expected: **no policies match** → no MFA would be required. This is the sign-in pattern we want. + +Then test untrusted scenario: +- Same user, same app +- IP: `8.8.8.8` (random external) +- Device: Compliant +- Expected: **Policy 1 matches** → MFA required. + +--- + +## Gate A3 — ALIS App Registration in Entra + +**Where:** Entra admin center → Applications → **App registrations** → **+ New registration** + +### A3.1 Register + +| Field | Value | +|---|---| +| Name | `Cascades of Tucson - ALIS SSO` | +| Supported account types | **Accounts in this organizational directory only (Default Directory only - Single tenant)** | +| Redirect URI — Platform | **Web** | +| Redirect URI — URL | `https://cascadestucson.alisonline.com/ExternalLoginCallback` | + +Click **Register**. + +### A3.2 Authentication + +Left sidebar → **Authentication**: +- Under **Implicit grant and hybrid flows** → check **ID tokens (used for implicit and hybrid flows)** +- Supported account types → **Accounts in this organization directory only (Default - Single tenant)** +- **Save** + +### A3.3 Client Secret + +Left sidebar → **Certificates & secrets** → **+ New client secret** + +| Field | Value | +|---|---| +| Description | `ALIS - Single Tenant Secret` | +| Expires | **24 months** (max — track in vault, renewal reminder required) | + +**Copy the `Value` immediately.** It's shown only once. Also capture the `Secret ID`. + +### A3.4 Capture the three values + +From **Overview** page: +- **Directory (tenant) ID:** `207fa277-e9d8-4eb7-ada1-1064d2221498` (known from existing tenant records) +- **Application (client) ID:** _capture after registration_ +- **Client Secret Value:** _captured in A3.3_ + +### A3.5 Vault the values + +Create `clients/cascades-tucson/alis-sso-app-registration.sops.yaml` with the three values + secret expiry date. Template: + +```yaml +kind: app-registration +name: Cascades ALIS SSO +tenant: cascadestucson.com +tenant_id: 207fa277-e9d8-4eb7-ada1-1064d2221498 +application_id: +client_secret_value: +secret_description: ALIS - Single Tenant Secret +secret_created: 2026-04-24 +secret_expires: 2028-04-24 +notes: | + Track expiration — IT admin must update ALIS App Store SSO settings with a new + secret each renewal cycle or sign-in will stop working for all linked users. + Rotation reminder: add to calendar 30 days before expires. +``` + +### A3.6 ALIS App Store install (YOUR SIDE, not Entra) + +Log into ALIS → App Store → search "Entra SSO" → Install → on the **Configure** tab, under **Outbound Connections**, paste: +- Directory ID +- Application ID +- Client Secret Value + +Save. + +--- + +## Gate A4 — Pilot AD account + +Run via GuruRMM on CS-SERVER (I'll execute when you say go): + +```powershell +# Generate a random initial password (you'll know it; caregiver won't need it since +# they'll set via self-service or login will SSO from phone directly) +$tempPass = -join ((65..90) + (97..122) + (48..57) | Get-Random -Count 16 | ForEach-Object {[char]$_}) + "!9" +$securePass = ConvertTo-SecureString $tempPass -AsPlainText -Force + +New-ADUser ` + -Name "Howard Enos" ` + -GivenName "Howard" ` + -Surname "Enos" ` + -SamAccountName "howard.enos" ` + -UserPrincipalName "howard.enos@cascadestucson.com" ` + -EmailAddress "howard.enos@cascadestucson.com" ` + -Path "OU=Caregivers,OU=Departments,DC=cascades,DC=local" ` + -AccountPassword $securePass ` + -Enabled $true ` + -ChangePasswordAtLogon $false ` + -Description "Phone SSO pilot test account — Howard's ALIS admin login target" + +Write-Output "Account created. Temporary password: $tempPass" + +# Add to SG-Caregivers (the group from G1) +Add-ADGroupMember -Identity "SG-Caregivers" -Members "howard.enos" + +# Verify +Get-ADUser howard.enos -Properties MemberOf, DistinguishedName, EmailAddress | + Select-Object SamAccountName, UserPrincipalName, EmailAddress, DistinguishedName, @{N='Groups';E={$_.MemberOf -join '; '}} +``` + +After run, vault the temporary password to `clients/cascades-tucson/howard-enos-pilot.sops.yaml` so we can find it later if needed. + +**ALIS side (you do):** in ALIS admin, update `howard.enos` staff profile's Email field to `howard.enos@cascadestucson.com` so it matches the Entra UPN. Required for SSO linking to resolve. + +--- + +## Gate A5 — Exit staging, sync, verify + +Run on CS-SERVER: + +```powershell +# Turn off staging mode +Set-ADSyncScheduler -SyncCycleEnabled $true +Set-ADSyncSchedulerConnectorOverride -ConnectorIdentifier "cascades.local" -FullSyncRequired + +# Open Azure AD Connect app from Start menu → Configure → Configure staging mode → UNCHECK "Enable staging mode" → Next → Configure + +# After exiting staging, force a full sync +Start-ADSyncSyncCycle -PolicyType Initial +``` + +Verify in Entra (https://entra.microsoft.com → Users): +- `howard.enos@cascadestucson.com` appears as hybrid (Source: Windows Server AD) +- The on-premises AD password hash should now be the M365 sign-in password + +Test sign-in at https://portal.office.com with `howard.enos@cascadestucson.com` + the temp AD password. Should succeed. **May** prompt for MFA at first sign-in depending on tenant defaults — that's fine. + +--- + +## Gate A6 — Enroll pilot phone + +**Phone choice:** fresh Samsung A15 (one of the 24 unopened), OR wipe the existing enrolled Phone 1. + +**Enrollment path:** MSDM shared-device mode, QR-code from `CSC - Android Shared Phones` profile (already configured in Intune). + +Steps: +1. Factory reset phone (if reused) +2. At first-boot, scan the QR code from `CSC - Android Shared Phones` +3. Phone enrolls into Intune, joins `Cascades - Shared Phones` dynamic group automatically (rule based on enrollmentProfileName) +4. Policies apply — compliance, Wi-Fi profile, required apps +5. Wait ~5–15 min for compliance to be evaluated + +**Test sign-in as pilot:** +- Open Teams or Authenticator → **Sign in** +- Enter `howard.enos@cascadestucson.com` + AD password +- **Expected (on Cascades Wi-Fi):** no MFA prompt (trusted location + compliant device → policies don't match) +- **Expected (off Cascades Wi-Fi):** MFA prompt (Policy 1 matches → require MFA + compliant) +- **ALIS web app:** should auto-SSO after M365 sign-in completes (ALIS OIDC app redirects to Entra for auth) + +**Verify in Entra sign-in logs:** +https://entra.microsoft.com → Monitoring & Health → Sign-in logs → filter User = howard.enos +- Column "Conditional Access" → should show "Report-only" results matching expected behavior +- Column "IP address" → should match `184.191.143.62` when on Cascades Wi-Fi (confirms Named Location matched) + +--- + +## Gate A7 — Flip CA to Enforcement (Monday AM) + +After review of Sat–Sun sign-in logs: +- Confirm no "would have been blocked" events for legitimate sign-ins +- Both CA policies → **Enable policy: On** (was Report-only) + +Run one more pilot sign-in from phone to confirm no regression. + +--- + +## Parallel: ALIS support email (send anytime) + +**To:** `support@medtelligent.com` +**Subject:** Cascades of Tucson — SSO setup, BAA request, and PIN feature availability + +``` +Hi ALIS team, + +I'm the MSP IT contact for Cascades of Tucson (tenant: cascadestucson.alisonline.com). +We are setting up Microsoft Entra SSO for our staff per your documentation at +https://support.alisonline.com/hc/en-us/articles/34831696021901. + +We have three asks: + +1. HIPAA Business Associate Agreement (BAA) — Cascades is a HIPAA-covered entity + and we need a signed BAA with Medtelligent / ALIS on file. Please send the + current template. + +2. User linking workflow — your documentation says users "link their ALIS account + to their Microsoft identity." Can you confirm whether linking is triggered by + administrator action (push) or by each user's first SSO sign-in attempt? + We are doing a controlled pilot rollout and need to know whether installing + the Entra SSO app will trigger any automatic re-linking for existing users, + or whether existing ALIS credentials keep working until each user is + individually linked. + +3. Login PINs feature — your docs note this is "limited-release." Is this + feature available to us? It looks valuable for our shared-phone caregiver + workflow (faster re-auth without full OIDC redirect each time). + +As a secondary item, we would also appreciate your FIPS 140-2 attestation / +compliance statement for our HIPAA risk analysis documentation. + +Happy to connect with your Integrations team as needed. + +Thanks, +Howard Enos +Arizona Computer Guru (MSP for Cascades of Tucson) +howard@azcomputerguru.com +``` + +--- + +## Rollback points + +| Gate | Rollback | +|---|---| +| A1 | Uninstall Entra Connect from Control Panel → nothing synced | +| A2 | Delete CA policies + Named Location — zero impact if Report-only | +| A3 | Delete App Registration in Entra — ALIS SSO stops working but ALIS credential login still works | +| A4 | Disable / remove `howard.enos` AD account | +| A5 | Re-enter staging mode via ADConnect wizard; re-sync to remove pilot from cloud | +| A6 | Factory reset phone | +| A7 | Flip both policies back to Report-only | + +No hard-to-reverse steps. Only concern: **after PHS is on, existing cloud-only M365 passwords for users in sync scope are overwritten by their AD password.** Phase 1 scope is just `howard.enos` (new account) — no existing-user password migration pain. + +--- + +## Open items / decisions as of 2026-04-24 + +- [ ] Dual-WAN verdict from pfSense (Howard to check after lockout clears) +- [ ] `72.211.21.217` egress IP — confirm or discard after Named Location Report-only logs show actual sign-in IPs +- [ ] ALIS support email sent +- [ ] ALIS BAA received +- [ ] Login PINs feature availability confirmed + +## Open questions handled elsewhere +- Everything Meredith-blocking → master plan Track B + `PLAN-AND-QUESTIONS-2026-04-24.md` §5 +- ALIS password pasted in chat earlier → rotate when convenient (post-pilot) diff --git a/clients/cascades-tucson/docs/security/risk-analysis-2026-04.md b/clients/cascades-tucson/docs/security/risk-analysis-2026-04.md new file mode 100644 index 0000000..c578f2e --- /dev/null +++ b/clients/cascades-tucson/docs/security/risk-analysis-2026-04.md @@ -0,0 +1,452 @@ +# HIPAA Security Rule Risk Analysis — Cascades of Tucson + +**Document ID:** RA-2026-04 +**Facility:** Cascades of Tucson (236-room assisted living + memory care community, Tucson AZ) +**Covered Entity:** Cascades of Tucson LLC +**Prepared by:** Howard Enos, Technician, Arizona Computer Guru (MSP) +**Reviewed by (Security Official):** Mike Swanson, President, Arizona Computer Guru (designated Security Official per §164.308(a)(2)) +**Counter-signed by (CE leadership):** Meredith Kuhn, Executive Director, Cascades of Tucson +**Date drafted:** 2026-04-24 +**Effective date:** On counter-signature +**Next review:** No later than 2027-04-24, or upon material change to environment, workforce, or threat landscape (§164.316(b)(2)(iii)) +**Supersedes:** None — this is the first formal Risk Analysis on file for Cascades of Tucson + +--- + +## 1. Purpose and regulatory basis + +HIPAA Security Rule §164.308(a)(1)(ii)(A) is a **Required** implementation specification: every covered entity must "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity." + +This document is that assessment. It follows the structure of **NIST SP 800-66 Revision 2 (Feb 2024) Section 3 — Risk Assessment Methodology**, which HHS OCR cites as the de-facto framework for Security Rule risk analyses. It is intentionally sized to the scale of Cascades — a single 236-room assisted living community with roughly 70 workforce members — rather than to the scale of a hospital. The goal is an audit-defensible analysis, not a gold-standard one. + +Where implementation specifications are **Addressable**, this document records the decision made, the rationale for that decision, and any compensating controls, as required by §164.306(d)(3). Addressable does not mean optional; it means the covered entity must either implement the spec, implement a reasonable alternative, or document a reasoned decision that neither is appropriate — and document that reasoning in writing. Decisions are cross-referenced to the **Security Rule Implementation Register** (`docs/security/implementation-register.md`, tracked as master-plan item B8). + +--- + +## 2. Scope (NIST 800-66r2 §3.1 — System Characterization) + +### 2.1 ePHI defined in the Cascades environment + +For purposes of this analysis, ePHI at Cascades means any electronic information that identifies a resident (name, room number, date of birth, Medicare/Medicaid ID, insurance info) combined with any information about the resident's health condition, medications, diagnoses, care plan, clinical imaging, incident reports, or service authorization. It does NOT include food-service-only data (kitchen iPad meal orders), facility-only data (work orders with no resident identifier), or marketing data that has never included resident health status. + +### 2.2 Workforce members in scope + +Based on the 2026-04-22 staff roster (`reports/cascades-staff-2026-04-22.csv`, ~70 rows): + +- **Clinical workforce** (handles PHI directly): Health Services Director, Health Services Manager, Memory Care Director, Memory Care Admin Assistant, Memory Care Nurses, Assisted Living Aides, MedTechs, Caregivers (approx. 39 net-new caregiver roles per Phase 1a rollout plan) +- **Administrative workforce with PHI access** (billing, admissions, records): Executive Director, Assistant Executive Director, Business Office Director, Accounting staff, Sales / Move-In Coordinator (limited — pre-admission assessment data) +- **Operational workforce with incidental PHI exposure**: Front Desk / Resident Services Receptionist (visitor logs, message-taking), Courtesy Patrol (incident reports), Life Enrichment (activity attendance + limited health accommodations), Drivers (pickup sheets with rider names + appointment context) +- **IT / admin workforce**: MSP technicians (Howard Enos, Mike Swanson) with role-based admin access; internal `sysadmin@` global admin. All IT access is subject to the Business Associate Agreement between Cascades and Arizona Computer Guru. +- **Out of scope**: Culinary / kitchen staff who do not enter the clinical wing and do not use ALIS. + +### 2.3 Systems in scope + +| System | Location | ePHI role | Owner | +|---|---|---|---| +| **ALIS** (go-alis.com / Medtelligent) | Cloud EHR (SaaS) | Primary clinical record — medications, care plans, assessments, incident logs | Medtelligent Inc. (Business Associate, BAA to be confirmed — item B2 in master plan) | +| **Microsoft 365** (cascadestucson.com) | Cloud — Exchange Online, OneDrive, SharePoint, Teams | PHI transit + at-rest in email bodies/attachments, staff OneDrive, planned Teams chat | Microsoft Corp. (Business Associate — **BAA not yet signed**, see §6.1.1) | +| **CS-SERVER** (192.168.2.254) | On-prem Windows Server 2016, Dell R610 (2009) | Primary on-prem file server, AD DC, DNS, DHCP, Hyper-V host for VoIP; hosts `\\CS-SERVER\homes` (user folder redirection target for PHI-generated documents) | Cascades (MSP-managed) | +| **Synology NAS** `cascadesds` (192.168.0.120) | On-prem, DSM 7 | Legacy file store — `Management`, `pacs`, `Server`, `Sandra Fish`, `homes` shares contain PHI. Scheduled for retirement in Phase 4. | Cascades (MSP-managed) | +| **Workstations** (staff PCs, ~18 audited) | On-prem | Browser access to ALIS, M365 mailboxes, SMB-mounted CS-SERVER / Synology shares | Cascades | +| **Shared caregiver phones** (Samsung A15, 25 units, Intune-managed) | Mobile | ALIS web app, Teams, Authenticator via Microsoft Shared Device Mode | Cascades (MSP-enrolled in Intune) | +| **pfSense firewall** (192.168.0.1) | On-prem | Enforces segmentation; terminates Cascades WAN | Cascades (MSP-managed) | +| **UniFi Wi-Fi** (CSCNet, CSC ENT, Guest) | On-prem | Transit for ePHI on phones and laptops | Cascades (MSP-managed) | + +### 2.4 Out-of-scope systems (documented so the scope is defensible) + +Kitchen iPads (food orders only, no resident health data), kitchen thermal printers (receipts), resident room VLANs (personal devices, no facility PHI), Ring security cameras (common areas, no clinical content), GoDaddy-hosted public website (no PHI), DirecTV entertainment infrastructure. If any of these systems are later used to process PHI, this scope statement must be updated. + +### 2.5 ePHI flows (simplified data-flow diagram) + +``` +Resident / family intake + │ + ▼ +Admissions (Sales / Move-In Coordinator) + ├── Paper → scanned → email / Management share → ALIS entry + │ +Clinical staff (RN, MedTech, Caregiver) + ├── ALIS (browser on workstation OR web app on Intune phone) + ├── Incident reports → Management share / email to Exec + ├── Paper MARs (non-electronic, outside this analysis) + │ +Executive / Business Office + ├── M365 mailbox (PHI in emails re: billing, hospice coordination, family) + ├── CS-SERVER homes share (folder redirection) + ├── Synology Management share (clinical admin docs) — LEGACY, Phase 4 retire + │ +MSP (Arizona Computer Guru) + ├── Remote admin via documented BAA scope (no casual PHI browsing) + ├── Backup storage (WSB → Synology — currently the only backup; HIPAA gap #1) + │ +External disclosures + ├── Microsoft (platform — BAA pending) + ├── Medtelligent/ALIS (EHR vendor — BAA pending confirmation) + ├── Pharmacy, hospice, hospital partners (outside IT scope — paper + fax) + └── Reliable Agency (contingent caregivers — workforce vs BA classification pending) +``` + +--- + +## 3. Data collection (NIST 800-66r2 §3.2 — ePHI inventory) + +Per §3.2 the risk analysis must enumerate where ePHI is created, received, maintained, or transmitted. The following inventory was compiled from `docs/security/hipaa.md`, `docs/migration/synology-permission-inventory.md`, `docs/cloud/m365.md`, `docs/servers/active-directory.md`, and `PROJECT_STATE.md`. + +### 3.1 ePHI at rest + +| Location | Type of ePHI | Approx. volume | Access method | At-rest encryption | Notes | +|---|---|---|---|---|---| +| ALIS cloud tenant | Full clinical records (MARs, care plans, assessments, incident logs, imaging refs) | All 236 residents, historical | HTTPS / browser / phone web app | Provider-managed (FIPS 140-2 per vendor attestation — to confirm with BAA) | Out of scope for Cascades infrastructure hardening; in scope for access-control + SSO | +| CS-SERVER `\\CS-SERVER\homes` | User-generated PHI (Word docs, Excel, PDFs dropped in redirected Documents/Downloads/Desktop) | Growing — every office user | SMB from staff PCs | BitLocker status on D: drive **not yet documented** (audit gap, master plan item) | SMB3 encryption is currently OFF; scheduled `Set-SmbShare -EncryptData $true` in master plan Part 6 | +| CS-SERVER other shares | Drive mappings (S:, M:, P:, etc.) | Per share | SMB | Same as homes | Folder-redirection destination shares must match homes encryption posture | +| Synology `Management` share | Clinical admin docs, billing refs, care plan exports | Active | SMB from workstations | ext4, not encrypted at-rest per audit | High-risk — Phase 4 retirement target | +| Synology `pacs` share | Likely imaging (PACS = Picture Archiving and Communication System naming convention) | Historical | SMB from workstations | ext4, not encrypted at-rest | Highest-risk Synology share | +| Synology `homes`, `Sandra Fish`, `Server`, `chat` shares | Mixed — user homes, historical director artifacts, staff chat logs | Active + legacy | SMB | ext4 | Contains PHI based on RW grants to clinical users | +| M365 Exchange Online mailboxes | PHI in emails, attachments, calendar invites | 34 licensed mailboxes | Outlook / OWA / mobile Outlook / phone web | Service-managed (Microsoft) | Licensed under BAA once signed | +| M365 OneDrive | Potential — users may save PHI to OneDrive unintentionally | Variable | Sync client / web | Service-managed | No DLP in place today | +| Staff workstation local disks | Cached Outlook OST, browser cache, downloaded attachments | 18 audited + ~10 more | Local | BitLocker broken or missing on 13 of 18 per audit 2026-03-20 | HIGH gap (master issue #12) | +| Caregiver shared phones (Samsung A15) | ALIS web app session data, Authenticator, Teams messages | 25 devices (1 enrolled, 24 in box) | Intune-managed | Device-level encryption required by compliance policy `CSC - Android Compliance` | Per-device enforcement verified on pilot device | +| Backup — Windows Server Backup → Synology SMB share | Full CS-SERVER image including PHI shares | Growing | SMB write from CS-SERVER | ext4 underlying volume, no BitLocker on target | Only backup that exists; no offsite copy (master issue #1 Critical) | + +### 3.2 ePHI in transit + +| Channel | Protocol | Encryption | Notes | +|---|---|---|---| +| Staff PC ↔ ALIS | HTTPS (TLS 1.2+) | Server-enforced | Good | +| Phone ↔ ALIS (web app in MSDM) | HTTPS (TLS 1.2+) | Server-enforced | Good | +| Staff PC ↔ M365 (Outlook, OWA, OneDrive sync) | HTTPS (TLS 1.2+) | Service-enforced | Good (Microsoft side); depends on BAA | +| Staff PC ↔ CS-SERVER SMB | SMB3 | SMB3 encryption currently OFF on `homes` (planned remediation) | See §6 H3 | +| Staff PC ↔ Synology SMB | SMB2/3 | Not encrypted | Phase 4 decommission | +| Email sent to external partners (pharmacy, hospice, hospital) | SMTP over TLS (opportunistic) | Variable depending on recipient MTA | No outbound DLP to enforce mandatory TLS + subject-line rules | +| MSP remote admin (Arizona Computer Guru) | Multiple tools (RMM, RDP) | TLS / NLA required per audit remediation (2026-03-20) | RDP-without-NLA findings have been resolved | +| Phone cellular / hotspot path | Carrier-side | Carrier-side | Conditional Access "Cascades Office" Named Location steers phones to Wi-Fi; off-network use is flagged | + +### 3.3 PHI creation points + +Every clinical shift generates ePHI. The most common creation points: +- **Caregiver documentation in ALIS** (per-resident tasks, observations) — phone or workstation +- **Incident reports** drafted in Word, emailed to Exec / Health Services Director, archived on `Management` or `homes` shares +- **Scanned intake paperwork** (admission, advance directives, physician orders) uploaded to ALIS or Management share +- **Internal email chains** re: hospice transition, hospital return, family care conferences — all contain PHI in message bodies + +--- + +## 4. Threats and vulnerabilities (NIST 800-66r2 §3.3 — Threat & Vulnerability Identification) + +The following threat sources are considered in this analysis, aligned to NIST SP 800-30r1 Appendix D categories: + +- **T-Adv** — Adversarial (external criminal attacker, opportunistic ransomware, targeted phishing, credential-stuffing, insider-turned-malicious) +- **T-Acc** — Accidental (workforce mistake — misaddressed email, wrong attachment, lost phone, accidental deletion) +- **T-Str** — Structural (equipment failure — the 16-year-old CS-SERVER is Exhibit A; disk failure, PSU failure, software bug, vendor outage) +- **T-Env** — Environmental (power loss, fire, water, HVAC failure, theft from facility) + +Each threat is paired with one or more environment-specific vulnerabilities drawn from the audit findings and the 2026-04-22 HIPAA review. + +### 4.1 Threat-vulnerability pairs specific to Cascades + +| # | Threat | Vulnerability at Cascades (grounded in repo docs) | Source | +|---|---|---|---| +| **TV-01** | T-Adv — credential theft / phishing | No MFA enforced on M365 historically (Security Defaults not enabled); 34 Business Standard accounts; some without recent password rotation | `docs/cloud/m365.md` line 14; master issue #15 | +| **TV-02** | T-Adv — ransomware / malware | 6 machines >3 months behind on Windows Updates; BitLocker broken or missing on 13 of 18 audited PCs; LAPS not deployed (same local admin password fleet-wide) | `docs/issues/audit-findings-2026-03-20.md` items #3, #12, #13 | +| **TV-03** | T-Adv — lateral movement post-compromise | krbtgt password 569+ days old; `RestrictAnonymous=0` fixed but LDAP channel binding not configured; Protected Users group empty | audit-findings items #20, #24, #25 | +| **TV-04** | T-Adv / T-Acc — shared-account abuse (anyone in a PHI-access role can sign in with no attribution) | **7 Synology shared-credential accounts** with RW to PHI shares: `Accounting`, `Dining Manager`, `Front Desk`, `mcnurse`, `Memcare Receptionist`, `memcarenurse`, `Nurse Tower`. Plus 3 workstation shared local accounts with NO password (NURSESTATION-PC `Nurses`, MEMRECEPT-PC `memfrtdesk`, RECEPTIONIST-PC `Front Desk`). | `docs/migration/synology-permission-inventory.md` §Shares; audit item #5 | +| **TV-05** | T-Adv — impersonation / business email compromise | No Defender anti-impersonation configuration on Business Standard; DMARC now at `p=quarantine` (2026-04-21) but spoofing recheck only had a 26-hour clean window at time of write | `docs/cloud/m365-impersonation-protection.md`; `reports/2026-04-21-post-dmarc-spoofing-recheck.md` | +| **TV-06** | T-Adv — third-party / BA exposure | Microsoft HIPAA BAA **not signed** (active Required-spec violation under §164.308(b)(1)); ALIS BAA not yet confirmed by Medtelligent; Reliable Agency workforce-vs-BA status undetermined | `docs/cloud/m365.md` line 12; HIPAA review 2026-04-22 C3, M3 | +| **TV-07** | T-Acc — misaddressed email containing PHI | Business Standard SKU has no DLP; no per-user outbound warning for PHI patterns (SSN, MRN) | `docs/cloud/m365.md` line 101 | +| **TV-08** | T-Acc — lost / stolen phone with an active ALIS session | Shared caregiver phones issued in a 24/7 facility; high physical turnover; phone compliance policy enforces 6-digit PIN + 1-minute inactivity + encryption, but the human can always hand off mid-session | `PROJECT_STATE.md` Intune rollout; ALIS web-app policy | +| **TV-09** | T-Acc — accidental over-share on SMB | `Everyone = Full Control` on multiple CS-SERVER shares (Culinary, directoryshare, Roaming per audit); PHI may land in the wrong share via folder redirection without the user realizing | audit item #14, #26 | +| **TV-10** | T-Str — CS-SERVER catastrophic hardware failure | 2009 Dell R610 — **16 years old** — is the ONLY domain controller, ONLY file server, ONLY DNS/DHCP, ONLY Hyper-V host. Ransomware / disk / PSU failure is an extinction event | audit item #2 Critical | +| **TV-11** | T-Str — no audit trail of PHI file access | CS-SERVER Object Access auditing currently disabled (`No Auditing`); Synology ext4 provides no auditable file-access log. If a breach happens we cannot tell who read what. | audit item #6 Critical; `docs/security/hipaa.md` gap #17 | +| **TV-12** | T-Str — data loss from lack of backup | CS-SERVER has no offsite backup. WSB → Synology is on-prem only and on the same physical power/fire/theft footprint. No M365 backup. | audit item #1 Critical | +| **TV-13** | T-Str — audit log retention below 6-year HIPAA floor | M365 audit default is 1 year, but §164.316(b)(2)(i) requires 6-year documentation retention | HIPAA review 2026-04-22 H1 | +| **TV-14** | T-Str — permissive firewall rule bleeds resident-VLAN traffic into staff VLAN | Floating pfSense rule #4 passes all IPv4 traffic, defeating room-to-room and resident-to-staff isolation | audit item #8 Critical | +| **TV-15** | T-Env — physical theft / loss of workstation | Low — facility is keycard-controlled during off hours — but any workstation with a local cache of PHI (OST, downloaded attachments) and broken BitLocker is a potential breach | audit item #12 combined with building access posture | +| **TV-16** | T-Env — power / water / fire | Single DC co-located with all facility IT in one room; no tested disaster-recovery runbook | `docs/security/hipaa.md` gap #1 | +| **TV-17** | T-Adv — former-employee access never revoked | Audit 2026-03-20 found 7 enabled-but-gone AD accounts + 5 disabled-but-not-deleted (cleaned 2026-04-13). Termination Procedures (§164.308(a)(3)(ii)(C)) not previously documented. | `docs/servers/active-directory.md` §Account Removals; HIPAA review C2 | +| **TV-18** | T-Adv — Kitchen iPad / resident-VLAN lateral access | 9 kitchen iPads on INTERNAL VLAN with access to staff resources; resident VLAN bleed per TV-14 | audit item #29 | +| **TV-19** | T-Adv — stale / unauthorized remote-access tooling | TightVNC on MEMRECEPT-PC; Splashtop on all 19 machines; Datto RMM on CS-SERVER; N-able Take Control, RemotePC, TeamViewer, GoTo all present from previous MSP | audit item #20 | +| **TV-20** | T-Acc — workforce not trained on Privacy Rule / sanctions | No evidence of annual HIPAA Privacy training records for non-clinical workforce (drivers, courtesy patrol, life enrichment, front desk) | HIPAA review 2026-04-22 H4 | + +--- + +## 5. Existing controls (NIST 800-66r2 §3.4 — Control Analysis) + +These are the controls **actually in place** as of 2026-04-24, not controls that are "planned" or "recommended." Planned controls are tracked in §7 Risk Treatment. + +### 5.1 Administrative safeguards in place + +| Control | Implementation | HIPAA cite | +|---|---|---| +| Designated Security Official | Mike Swanson, Arizona Computer Guru (MSP Owner) | §164.308(a)(2) | +| MSP Business Associate relationship | Arizona Computer Guru operates under BAA with Cascades | §164.308(b)(1) | +| Workforce access controls via AD security groups | Security groups `SG-Management-RW`, `SG-Sales-RW`, `SG-Server-RW`, `SG-Chat-RW`, `SG-Culinary-RW`, `SG-IT-RW`, `SG-Receptionist-RW`, `SG-Directory-RW`, `SG-Caregivers` created 2026-04-22; role-based access model | §164.308(a)(4) | +| Termination — same-day account disable practice | Implemented 2026-04-22 for Britney Thompson (prior to litigation-hold remediation) | §164.308(a)(3)(ii)(C) | +| AD Recycle Bin enabled | Enables account recovery within 180 days; confirmed 2026-03-21 | §164.308(a)(7) supports integrity | +| MSP change documentation | All changes logged to `session-logs/`, `reports/`, and `PROJECT_STATE.md`; master plan in `PLAN-AND-QUESTIONS-2026-04-24.md` | §164.316(b)(1) | + +### 5.2 Physical safeguards in place + +| Control | Implementation | HIPAA cite | +|---|---|---| +| Keycard-controlled facility access | Standard assisted-living physical access controls | §164.310(a)(1) | +| CS-SERVER in locked IT room | Confirmed via onsite visits | §164.310(a)(2)(ii) | +| Intune device inventory for mobile tier | 25 Samsung A15 shared phones enrolled or queued; dynamic device-group membership via enrollment profile | §164.310(d)(1) | +| Workstation siting | Front-desk workstations visible to staff only; clinical workstations in nurse stations not accessible to residents | §164.310(b) | + +### 5.3 Technical safeguards in place + +| Control | Implementation | HIPAA cite | +|---|---|---| +| Unique User ID — office staff | All M365 staff have personal `first.last@` UPNs (shared mailboxes are access-delegated, not shared-credential) | §164.312(a)(2)(i) | +| Unique User ID — caregivers (mobile tier) | MSDM-based per-user Entra sign-in on shared phones; each caregiver has own AD + Entra identity | §164.312(a)(2)(i) | +| Automatic logoff — mobile tier | Android compliance policy enforces 1-minute inactivity screen lock + 6-digit numericComplex PIN; encryption required; root + SafetyNet + App Integrity enforced | §164.312(a)(2)(iii) Addressable | +| Transmission encryption — M365 | TLS 1.2+ enforced by Microsoft for Outlook / OWA / OneDrive / Teams | §164.312(e)(1) | +| Transmission encryption — ALIS | TLS 1.2+ enforced by Medtelligent | §164.312(e)(1) | +| Encryption at rest — mobile tier | Android Enterprise device-level encryption required by compliance policy | §164.312(a)(2)(iv) Addressable | +| Person / entity authentication — office users | M365 password-based, MFA will be enforced by Conditional Access post-Entra-Connect | §164.312(d) | +| Person / entity authentication — caregivers | Entra ID + MSDM + Conditional Access "Cascades - Phone MFA Exception" (MFA waived only when user ∈ `SG-Caregivers` AND device compliant AND sign-in from Cascades WAN IP); MFA required everywhere else | §164.312(d) | +| DMARC | Policy `p=quarantine; pct=100` deployed 2026-04-21 (Mike); SPF and DKIM in place | §164.312(e)(1) supports transmission integrity | +| DMARC post-deploy verification | Spoofing recheck `reports/2026-04-21-post-dmarc-spoofing-recheck.md` confirmed quarantine working 26h clean window | §164.312(e)(1) | +| Malware protection | Windows Defender + MSP AV agent (Datto AV migrating to GuruRMM stack) | §164.308(a)(5)(ii)(B) | +| MSP-managed patching | GuruRMM AutoPatch running; 5 of 6 critically behind machines patched overnight 2026-03-20 | §164.308(a)(5)(ii)(B) | +| Account lockout | 5 attempts / 30 minutes, enforced in Default Domain Policy 2026-03-09 | §164.308(a)(5)(ii)(D) | +| MDM compliance + restrictions | Intune config profile `CSC - Android Shared Phones Restrictions` (factoryResetBlocked, no USB, no unknown sources, screenCaptureBlocked, no dev settings, update window 02:00-06:00 UTC); `CSC - CSCNet Wi-Fi (WPA2-Personal)` | §164.310(d), §164.312(a)(1) | +| RDP hardened | NLA required on all remaining RDP endpoints; audit finding for ASSISTMAN-PC + DESKTOP-U2DHAP0 resolved 2026-03-20 | §164.312(e)(1) | +| Remote-access tooling consolidation | Plan in place; TightVNC and legacy MSP tools flagged for removal | §164.312(a)(1) | + +### 5.4 Organizational safeguards in place + +| Control | Implementation | HIPAA cite | +|---|---|---| +| Business Associate relationships identified | Microsoft (BAA pending, item B1 — this is an active gap), Medtelligent/ALIS (pending confirmation, item B2), Arizona Computer Guru (executed) | §164.308(b)(1) | +| Policy & procedure documentation | This Risk Analysis + Security Rule Implementation Register (B8, in drafting) + Termination Procedures (B4, in drafting) + Synology shared-login risk-acceptance form (B6, in drafting) | §164.316(b)(1) | + +--- + +## 6. Risk determination — likelihood × impact (NIST 800-66r2 §3.5) + +Likelihood and impact are rated on a low / medium / high scale using the following rubric tailored to a single-facility covered entity: + +- **Likelihood — Low**: event plausible but has not been observed in this environment or comparable ones in the last 24 months, AND existing controls materially reduce exposure. +- **Likelihood — Medium**: event has been observed in comparable environments (assisted living, small healthcare) in the last 24 months, OR existing controls have known gaps. +- **Likelihood — High**: event has been observed in this environment OR is actively present as an unresolved gap on the day this analysis is signed. +- **Impact — Low**: small number of records (<10 residents), limited to non-sensitive categories (e.g., scheduling), recoverable without OCR notification. +- **Impact — Medium**: moderate exposure (10–100 records) or single sensitive record (e.g., memory-care diagnosis disclosed externally); may trigger state breach-notification law (AZ has a 45-day notification clock for >1,000 residents — Cascades is below this threshold but OCR reporting still applies). +- **Impact — High**: bulk exposure (≥100 records), full facility record loss, OR operational continuity hit (ALIS inaccessible for >24 hours during a clinical shift). + +**Overall risk tier**: [CRITICAL] is reserved for pairs that are High × High; [HIGH] for High × Medium or Medium × High; [MEDIUM] for Medium × Medium or Low × High / High × Low; [LOW] for all others. + +### 6.1 Risk ratings per threat-vulnerability pair + +| # | Threat-vuln | Likelihood | Impact | Tier | Rationale | +|---|---|---|---|---|---| +| **TV-01** | Credential theft / phishing — no MFA historically | Medium | High | **[HIGH]** | Controls improving (DMARC, planned CA, planned Entra Connect + MFA) but baseline today is still pre-MFA. An admin mailbox compromise today gives full M365 tenant access. | +| **TV-02** | Ransomware / malware — patch + BitLocker gaps | Medium | High | **[HIGH]** | 5 of 6 critically-behind machines have been patched, but BitLocker is broken on 13 of 18 PCs, and LAPS is not deployed. A ransomware hit on CS-SERVER combined with TV-12 (no offsite backup) is an extinction event. | +| **TV-03** | Lateral movement / AD compromise | Medium | High | **[HIGH]** | krbtgt is overdue for rotation; LDAP channel binding not configured; Protected Users empty. Post-compromise blast radius is extreme because CS-SERVER is the only DC. | +| **TV-04** | Shared-account abuse on Synology + shared workstations | **High** | **High** | **[CRITICAL]** | 7 Synology shared logins are a present-tense Required-spec violation. 3 workstation shared accounts have no password. Active-ongoing gap; must be addressed with Phase 4 cutover + interim risk acceptance (B6). | +| **TV-05** | Impersonation / BEC | Low | High | **[MEDIUM]** | DMARC is now at `p=quarantine` with a clean recheck; no Defender anti-impersonation but DMARC materially lowers likelihood. Impact remains high because Executive Director mailbox is a high-value target. | +| **TV-06** | BA not in place (Microsoft + ALIS) | **High** | High | **[CRITICAL]** | Microsoft BAA unsigned = active Required-spec violation under §164.308(b)(1). Every day of use is a continuing violation. Remediation is a 5-minute portal click (master plan B1 / T0-3). ALIS BAA confirmation is a 1-email 1-2-week turnaround (B2). | +| **TV-07** | Misaddressed email / DLP gap | Medium | Medium | **[MEDIUM]** | No DLP today. Small-facility email volumes keep likelihood moderate. Business Premium upgrade (Track C / Phase 1a) unlocks DLP. | +| **TV-08** | Lost / stolen shared phone mid-session | Medium | Medium | **[MEDIUM]** | Compliance-policy 1-minute inactivity + 6-digit PIN + device encryption + Intune remote wipe make data-at-rest exposure low; mid-session handoff is the residual concern. | +| **TV-09** | Over-share on SMB / wrong share | Medium | Medium | **[MEDIUM]** | `Everyone=FullControl` on Culinary/directoryshare/Roaming is flagged; folder-redirection destination `homes` is already scoped per-user. Remediation path exists (security groups + NTFS tightening). | +| **TV-10** | CS-SERVER hardware failure | Medium | **High** | **[HIGH]** | 16-year-old Dell R610 is well past vendor-supported life. Operational-continuity impact dwarfs the confidentiality impact. Hardware replacement is a Track C / Wave 5 work item (Q39). | +| **TV-11** | No audit trail of PHI file access | **High** | **High** | **[CRITICAL]** | Required spec §164.312(b). CS-SERVER Object Access auditing is disabled today; Synology ext4 provides no file-access log. Breach attribution impossible. | +| **TV-12** | Data loss from backup gap | Medium | **High** | **[HIGH]** | WSB → Synology exists but is co-located; no offsite; no M365 backup. A single site event = total loss. | +| **TV-13** | Audit log retention <6 years | **High** | Medium | **[HIGH]** | M365 default 1-year retention < §164.316(b)(2) 6-year floor. Continuously out of compliance. Decision pending (B5). | +| **TV-14** | Pfsense floating rule #4 / VLAN bleed | Medium | High | **[HIGH]** | Resident VLAN can reach staff VLAN today. Any infected resident device has a path to staff resources. Phase 1.6 scoped-rule replacement. | +| **TV-15** | Physical theft of workstation with broken BitLocker | Low | Medium | **[MEDIUM]** | Facility access controls reduce likelihood; but 13 of 18 PCs lacking real disk encryption means any single theft = potential cached-PHI exposure. | +| **TV-16** | Environmental — power / fire / water | Low | High | **[MEDIUM]** | Commercial building, HVAC-conditioned IT room; no tested DR runbook. Likelihood low but recovery posture is weak if it happens. | +| **TV-17** | Former-employee access not revoked | Low | Medium | **[MEDIUM]** | Post-2026-04-13 AD cleanup and 2026-04-22 M365 orphan deletes have closed this. Formal Termination Procedures (B4) will lock the improvement in. | +| **TV-18** | Kitchen iPad / resident VLAN lateral access | Medium | Medium | **[MEDIUM]** | 9 kitchen iPads on INTERNAL VLAN; no PHI on iPads themselves but they could be a pivot point. Restrict-to-printer-IPs rule is planned. | +| **TV-19** | Stale / unauthorized remote-access tooling | Medium | High | **[HIGH]** | TightVNC on MEMRECEPT-PC is unauthorized remote access with no password — a direct admin-level foothold if discovered. Other tools are legitimate-MSP but over-installed. | +| **TV-20** | Workforce not formally trained on Privacy Rule | Medium | Medium | **[MEDIUM]** | No evidence of annual Privacy Rule training records for non-clinical workforce; §164.530(b)(1) is a Privacy Rule training requirement (operationally relevant to Security Rule sanctions). | + +### 6.2 Top-tier risks summary + +**[CRITICAL] — must be resolved or formally risk-accepted before next review:** +- TV-04 — shared-credential accounts with PHI access +- TV-06 — Microsoft BAA unsigned (continuing Required-spec violation) +- TV-11 — no audit trail for PHI file access + +**[HIGH] — actively being remediated in master plan Track A / B / C:** +- TV-01, TV-02, TV-03, TV-10, TV-12, TV-13, TV-14, TV-19 + +--- + +## 7. Risk treatment plan (NIST 800-66r2 §3.6 — Risk Response) + +Each risk is assigned a treatment posture: **Mitigate**, **Transfer** (to a Business Associate via BAA), **Accept** (with documented residual-risk acknowledgment), or **Avoid** (stop doing the thing that creates the risk). Addressable-spec decisions are recorded here and cross-referenced to the **Security Rule Implementation Register** (`docs/security/implementation-register.md`, item B8 in master plan). + +### 7.1 Required specifications — must be implemented + +| Spec | Status | Action | +|---|---|---| +| §164.308(a)(1)(ii)(A) Risk Analysis | In progress — **this document** | Counter-sign, file, schedule annual review 2027-04-24 | +| §164.308(a)(3)(ii)(C) Termination Procedures | Documentation pending (B4 in master plan) | Howard drafts from current same-day-disable practice; Mike + Meredith sign; filed by 2026-05-02 | +| §164.308(b)(1) Business Associate contracts — **Microsoft** | **Active violation** | T0-3: Meredith signs Microsoft HIPAA BAA via M365 Admin Center → Settings → Org Settings → Security & Privacy → HIPAA BAA. 5 minutes. Target: before Phase 1 caregiver pilot sign-in. | +| §164.308(b)(1) Business Associate contracts — **Medtelligent/ALIS** | Pending confirmation | B2: Meredith / ALIS support — 1-2 week vendor turnaround. Parallel to Track A. | +| §164.312(a)(2)(i) Unique User Identification — office staff | Implemented | Preserve in Implementation Register | +| §164.312(a)(2)(i) Unique User Identification — Synology | **Active violation (7 shared accounts)** | Path: (a) Phase 4 Synology retirement, OR (b) accelerated disable now with workflow disruption. Interim: Meredith signs risk-acceptance form (B6) with compensating controls — physical access control + shift sign-in sheets + monthly SMB access-log review by Howard — pending until Phase 4 cutover date. | +| §164.312(a)(2)(i) Unique User Identification — workstation shared local accounts | Active violation | 3 PCs (NURSESTATION-PC `Nurses`, MEMRECEPT-PC `memfrtdesk`, RECEPTIONIST-PC `Front Desk`) with passwordless shared logins. Resolved when Phase 3 domain join + Phase 5 shared-account replacement completes. Interim: same risk-acceptance form (B6) applies. | +| §164.312(b) Audit Controls | Partially implemented | CS-SERVER: enable Object Access auditing in Wave 5 hardening (documented in Implementation Register). Synology: accept that ext4 provides no audit trail; retire in Phase 4. M365: see §164.316(b)(2) below. | +| §164.312(d) Person / Entity Authentication | In progress | Post-Entra-Connect: Conditional Access policy "Cascades - Phone MFA Exception" (Report-only → On) gates office staff + caregivers. Office staff get standard MFA; caregivers get the building-only Named Location exception by design. | +| §164.316(b)(1) Policies & Procedures documentation | In progress | Implementation Register (B8) is the single index. Each policy/procedure links back to the Register row and cites this Risk Analysis. | +| §164.316(b)(2)(i) 6-year retention of documentation | Decision pending — **three options**, see §7.3 | | + +### 7.2 Addressable specifications — decision record + +For each Addressable spec, HIPAA requires a documented decision: implement as specified, implement an alternative, OR document why neither is reasonable and appropriate. + +| Spec | Decision | Rationale | Alternative / compensating control | Owner | Register row | +|---|---|---|---|---|---| +| §164.308(a)(7)(ii)(A) Data Backup Plan | **Implement** (in progress) | WSB → Synology exists; offsite is a gap | Offsite backup target to be added in Wave 5. Interim: accept co-located backup with documented recovery runbook | Howard | Reg-01 | +| §164.308(a)(7)(ii)(B) Disaster Recovery Plan | **Implement (abbreviated)** | Single-facility CE, no distributed ops | Written DR runbook for CS-SERVER rebuild; tested annually | Howard + Mike | Reg-02 | +| §164.308(a)(7)(ii)(C) Emergency Mode Operation | **Implement (paper fallback)** | ALIS outage / network outage → paper MAR sheets; documented in Health Services SOP (not an IT deliverable — flag for Meredith + Lois Lane) | N/A | Meredith + Lois Lane | Reg-03 | +| §164.310(d)(2)(i) Disposal | **Implement** | Decommissioned drives destroyed via NIST SP 800-88 sanitization or physical shredding per MSP procedure | N/A | Howard | Reg-04 | +| §164.310(d)(2)(ii) Media Re-use | **Implement** | Same procedure as Disposal before re-use | N/A | Howard | Reg-05 | +| §164.312(a)(2)(ii) **Emergency Access Procedure** | **Documented decision — current posture retained** | Two named global admins (`sysadmin@` — Howard; Mike — via his Arizona Computer Guru admin identity), both Arizona-based, both contactable 24/7 via MSP on-call. Microsoft support portal provides documented tenant-recovery path for lost-admin scenarios. **No specific hardware requirement (FIDO2 / YubiKey / otherwise) is prescribed by §164.312(a)(2)(ii) and none is adopted at this time.** This decision will be revisited if: (a) the admin pair changes such that both are no longer geographically diverse or availability-diverse, (b) the tenant adds additional high-sensitivity workloads, OR (c) the annual review finds the current posture inadequate. | 24/7 MSP on-call + Microsoft support tenant-recovery procedures | Mike (Security Official) | Reg-06 | +| §164.312(a)(2)(iii) Automatic Logoff — mobile tier | **Implement** | Intune `CSC - Android Compliance`: 1-minute inactivity lock, 6-digit PIN, device encryption | N/A | Howard | Reg-07 | +| §164.312(a)(2)(iii) Automatic Logoff — shared workstations | **Implement** | Planned GPO `CSC - Shared Workstation`: screen lock 10-min idle, sign-out 30-min idle, Fast User Switching disabled | N/A | Howard | Reg-08 | +| §164.312(a)(2)(iv) Encryption & Decryption (at rest) | **Implement** | BitLocker on all workstations (Wave 5); BitLocker verification on CS-SERVER D: drive (audit gap); SMB3 encryption on `\\CS-SERVER\homes` scheduled via master plan Part 6 | N/A | Howard | Reg-09 | +| §164.312(e)(2)(i) Integrity controls (in transit) | **Implement** | TLS 1.2+ everywhere; DMARC `p=quarantine`; SMB3 signing | N/A | Howard + Mike | Reg-10 | +| §164.312(e)(2)(ii) Encryption (in transit) | **Implement** | Same as §164.312(e)(2)(i) | N/A | Howard | Reg-11 | + +### 7.3 Audit log retention — option set (§164.316(b)(2)(i)) + +Per the HIPAA review 2026-04-22 H1, M365 audit default of 1 year is below the 6-year documentation-retention floor. **Decision pending** (Meredith, master plan item B5). Three options are on the table; no specific product is mandated by HIPAA: + +- **Option A — Microsoft Purview Audit (Premium) add-on.** 10-year audit log retention. Approximately $3/user/month. +- **Option B — M365 Compliance retention policy at 7 years.** $0 incremental if Cascades proceeds with the Business Premium tenant-wide upgrade already teed up for Phase 1a. +- **Option C — Monthly export to immutable Azure Blob Storage.** $0 licensing; requires a scheduled script and monitoring. Operational burden falls on the MSP. + +Each option is reasonable and appropriate under §164.316(b)(2). The master plan flags Option B as the default path because it stacks on a purchase already planned, but **the formal choice and Implementation Register entry are pending Meredith's direction**. + +### 7.4 Track A / B / C master-plan cross-references + +The master plan (`PLAN-AND-QUESTIONS-2026-04-24.md`) is the operational artifact that remediates these risks on a schedule: + +- **Track A (phones-first pilot, target Monday 2026-04-27)** — addresses TV-01 (MFA via CA), TV-04 (per-person caregiver identities on phones via MSDM), TV-06 (Microsoft BAA T0-3), partial TV-08 (compliance policy already live), TV-09 (by design caregivers don't touch SMB shares). +- **Track B (HIPAA baseline — this Risk Analysis is B3)** — B1 Microsoft BAA, B2 ALIS BAA, B3 this doc, B4 Termination Procedures, B5 audit-retention decision, B6 Synology risk acceptance, B7 Emergency Access decision, B8 Security Rule Implementation Register. +- **Track C (later phases)** — Phase 2/3 sync (remaining TV-04, TV-17), Phase 4 Synology retirement (closes TV-04 on the Synology side), Phase 5 shared-account replacement (closes TV-04 on workstation side), Wave 5 hardening (TV-02, TV-03, TV-11, TV-12 remaining gaps, new DC hardware for TV-10). + +--- + +## 8. Residual risks (after planned controls are in place) + +Even after master-plan Tracks A through C are complete, the following residual risks remain. These are the risks Cascades knowingly carries, per the Security Rule's "reasonable and appropriate" standard (§164.306(b)). + +| # | Residual risk | Why it remains | Tier | Compensating posture | +|---|---|---|---|---| +| **R-1** | **Synology shared-login exposure until Phase 4 cutover** | Workflow disruption of immediate disable exceeds acceptable operational risk to resident care. Phase 4 retirement is scheduled but weeks-to-months away depending on John Trozzi input on share usage. | **[HIGH]** | Physical facility access control, shift-based workstation sign-in sheets, monthly SMB access-log review by Howard, Meredith signs risk-acceptance form (B6). Reviewed at each Wave milestone. | +| **R-2** | **CS-SERVER single-point-of-failure until hardware refresh** | 16-year-old Dell R610 remains the only domain controller until new server + second DC in Wave 5 / Track C. Hardware replacement requires capex approval from Meredith (Q39). | **[HIGH]** | Daily WSB backup (on-prem), extracted warranty coverage (none — hardware is out of support), runbook for emergency rebuild, PRTG + GuruRMM alerting on CS-SERVER service status. | +| **R-3** | **Audit-trail completeness for pre-CS-SERVER / pre-ALIS activity** | Object Access auditing was off prior to Wave 5 hardening. Historical file-access events on CS-SERVER cannot be reconstructed. | **[MEDIUM]** | Going-forward auditing meets §164.312(b); documented in Register as a point-in-time baseline. | +| **R-4** | **Third-party BA chain** | Microsoft and Medtelligent are BAs; their own BAs and subcontractors are not individually visible to Cascades | **[MEDIUM]** | Reliance on BAA obligations for downstream BAs per §164.308(b)(2) and §164.314(a)(2)(i)(B); no further diligence required of CE. | +| **R-5** | **Business Standard SKU limits on DLP + anti-impersonation + Defender** | Full DLP + anti-impersonation require Business Premium / Defender P1-P2. Tenant-wide Business Premium is teed up for Phase 1a but not yet purchased. | **[MEDIUM]** | DMARC `p=quarantine` is in place; targeted protection will follow the purchase. Mailbox monitoring by MSP continues. | +| **R-6** | **No immutable offsite backup** | Current WSB → Synology is co-located. Offsite destination + immutability are Wave 5 work. | **[MEDIUM]** | Physical controls reduce likelihood of total-site loss; still not acceptable long-term. Target: Wave 5. | +| **R-7** | **Conditional Access "Cascades Office" Named Location depends on static WAN IP** | If Cox rotates the pfSense WAN IP, CA exception fails open (MFA prompts everywhere) or closed (locks caregivers out) depending on posture. | **[LOW]** | T0-2 is to verify WAN IP is static on the Cox circuit. If not static, a Named Location update hook (scheduled script or MSP runbook) is required. Documented as Register row when CA goes live. | +| **R-8** | **Reliable Agency workforce vs BA classification** | If Reliable staff work under agency direction and access ALIS independently, Reliable is a Business Associate requiring a BAA. If they work under Cascades direction, they are workforce and subject to Cascades training/sanctions. | **[LOW]** | No independent PHI access until classification is resolved (HIPAA review M3). Agency caregivers work under Cascades-employed caregiver supervision in the interim. | + +--- + +## 9. Methodology limitations and information-gap flags + +This analysis was drafted from repository documentation and MSP onsite observations. The following items could **not** be confirmed from repo docs and need CE / leadership input before the next review cycle: + +1. **ALIS vendor attestation on FIPS 140-2 validated cryptography** — cited in §3.1 but not in repo; requires ALIS support confirmation (tied to B2 BAA work). +2. **BitLocker state on CS-SERVER D: drive** — documented as a gap in HIPAA review H3; needs Howard onsite or SSH verification. +3. **Annual Privacy Rule training records for non-clinical workforce** — §164.530(b)(1); requires Meredith to confirm if training has been delivered, by whom, and whether signed acknowledgments exist. +4. **Sanctions policy for workforce HIPAA violations** — §164.530(e); Meredith to confirm if Cascades has a written sanctions policy separate from general HR discipline. +5. **Reliable Agency staffing contract language** — workforce-vs-BA classification (R-8); Meredith to provide. +6. **Historical breach / complaint records** — whether any past OCR inquiry, state DOI referral, or resident / family HIPAA complaint exists at Cascades; affects "documented history of incidents" in future risk analyses. +7. **Paper PHI handling** — paper MARs, pickup sheets, incident report forms; outside the electronic-only scope of this analysis but within the CE's overall Privacy Rule obligations. +8. **Physical safeguards audit for remote workforce** — if any workforce member (e.g., Executive Director on PTO) accesses PHI from a personal home network, home-office safeguards belong in this analysis. Not currently observed. +9. **State-law overlays** — Arizona medical-records retention (7 years post-last-encounter), Arizona breach notification thresholds. Addressed at the CE-leadership / legal-counsel level, not by MSP. + +Each item above is flagged for next-review closure. None individually invalidates this analysis. + +--- + +## 10. Signatures + +By signing below, the parties acknowledge that this Risk Analysis has been reviewed and accepted as the current risk baseline for Cascades of Tucson, and that the risk-treatment plan in §7 and residual-risk acknowledgments in §8 reflect the covered entity's formal position as of the effective date. + +**Prepared by (MSP Technician):** + +Howard Enos — Arizona Computer Guru + +Signature: ____________________________________ Date: ____________ + +**Approved by (Designated HIPAA Security Official):** + +Mike Swanson — President, Arizona Computer Guru LLC + +Signature: ____________________________________ Date: ____________ + +**Counter-signed by (Covered Entity leadership):** + +Meredith Kuhn — Executive Director, Cascades of Tucson + +Signature: ____________________________________ Date: ____________ + +--- + +## Appendix A — Control inventory (existing + planned) + +| ID | Control | Status | HIPAA cite | Source | +|---|---|---|---|---| +| CTL-01 | Designated HIPAA Security Official | In place | §164.308(a)(2) | Mike Swanson | +| CTL-02 | Business Associate Agreement — Microsoft | **Pending (active violation)** | §164.308(b)(1) | Master plan B1 / T0-3 | +| CTL-03 | Business Associate Agreement — Medtelligent (ALIS) | Pending confirmation | §164.308(b)(1) | Master plan B2 | +| CTL-04 | Business Associate Agreement — Arizona Computer Guru (MSP) | In place | §164.308(b)(1) | Executed | +| CTL-05 | AD security groups for role-based access (`SG-*`) | In place (created 2026-04-22) | §164.308(a)(4)(i) | `docs/servers/active-directory.md` | +| CTL-06 | AD Recycle Bin | In place (2026-03-21) | §164.308(a)(7) support | audit item log | +| CTL-07 | Same-day termination disable | In practice (Britney Thompson 2026-04-22) | §164.308(a)(3)(ii)(C) | HIPAA review | +| CTL-08 | Written Termination Procedure | In drafting (B4) | §164.308(a)(3)(ii)(C) | Master plan | +| CTL-09 | Formal Risk Analysis (this document) | In drafting / signature | §164.308(a)(1)(ii)(A) | This doc | +| CTL-10 | Security Rule Implementation Register | In drafting (B8) | §164.316(b)(1) | Master plan | +| CTL-11 | Synology shared-login risk-acceptance form | In drafting (B6) | §164.306(b) | Master plan | +| CTL-12 | M365 MFA via Conditional Access | Planned (Track A A7) | §164.312(d) | Master plan | +| CTL-13 | M365 Security Defaults (pre-CA baseline) | Planned fallback if CA delays | §164.312(d) | Master plan | +| CTL-14 | DMARC `p=quarantine; pct=100` | In place (2026-04-21) | §164.312(e) support | `reports/2026-04-21-post-dmarc-spoofing-recheck.md` | +| CTL-15 | SPF + DKIM | In place | §164.312(e) support | m365.md | +| CTL-16 | Intune Android compliance policy | In place (2026-04-21) | §164.312(a)(2)(iii)(iv) | PROJECT_STATE | +| CTL-17 | Intune device restrictions config profile | In place | §164.310(d), §164.312(a)(1) | PROJECT_STATE | +| CTL-18 | MSDM (Microsoft Shared Device Mode) for caregiver phones | In place | §164.312(a)(2)(i), (d) | PROJECT_STATE | +| CTL-19 | Conditional Access Named Location "Cascades Office" | Planned (Track A A2) | §164.312(a)(1), (d) | Master plan | +| CTL-20 | SMB3 encryption on `\\CS-SERVER\homes` | Planned (Part 6 executable) | §164.312(e)(2)(ii) | Master plan | +| CTL-21 | BitLocker on workstations | Gap (13 of 18 broken/missing) | §164.312(a)(2)(iv) | audit-findings #12 | +| CTL-22 | LAPS (Windows Local Administrator Password Solution) | Planned (Wave 5) | §164.312(a)(1) | audit-findings #13 | +| CTL-23 | CS-SERVER Object Access auditing | Planned (Wave 5) | §164.312(b) | audit-findings #17 | +| CTL-24 | krbtgt password rotation (180-day cadence) | Planned (Wave 5) | §164.312(a)(1) | audit-findings #20 | +| CTL-25 | Protected Users group population | Planned (Wave 5) | §164.312(a)(1) | audit-findings #25 | +| CTL-26 | Offsite backup (immutable) | Planned (Wave 5) | §164.308(a)(7)(ii)(A) | audit-findings #1 | +| CTL-27 | Second domain controller + hardware refresh | Planned (Track C Wave 5) | §164.308(a)(7) support | audit-findings #2 | +| CTL-28 | RDP with NLA | In place | §164.312(e)(1) | audit-findings #19 (closed) | +| CTL-29 | Account lockout (5 attempts / 30 min) | In place | §164.308(a)(5)(ii)(D) | audit-findings #18 | +| CTL-30 | Annual Risk Analysis review | Annual cadence (next 2027-04-24) | §164.308(a)(1)(ii)(A) | This doc §10 | +| CTL-31 | Audit log retention to 6-year floor | Option A / B / C — decision pending (B5) | §164.316(b)(2) | Master plan | +| CTL-32 | Emergency Access Procedure — documented admin posture | In place (this doc §7.2) | §164.312(a)(2)(ii) | This doc | + +--- + +## Appendix B — Cross-reference to 2026-04-22 HIPAA review findings + +| Review finding | Status in this Risk Analysis | +|---|---| +| A1 — Synology shared-login accounts | TV-04 / R-1, risk-accepted via B6 until Phase 4 | +| C1 — agency shared logins (reliable1/reliable2) | Resolved 2026-04-22 (not created); individual accounts required | +| C2 — Britney Thompson litigation hold | Documented in Termination Procedures (B4) | +| C3 — Microsoft BAA unsigned | TV-06 — active Required-spec violation, T0-3 | +| C4 — no formal Risk Analysis | **This document resolves that finding** | +| H1 — M365 audit log retention | TV-13, decision pending (B5) | +| H2 — break-glass admin account | Superseded: §7.2 Emergency Access Procedure decision (two-admin posture + Microsoft recovery path, no hardware prescription) | +| H3 — SMB3 encryption + BitLocker on CS-SERVER | CTL-20, CTL-21 | +| H4 — drivers + Privacy Rule training | §9 information-gap item 3 | +| M1 — automatic logoff timers | CTL-07 (mobile) / Reg-08 (shared workstations) | +| M2 — Security Rule Implementation Register | CTL-10 (B8) | +| M3 — Reliable Agency BA classification | R-8 | +| M4 — Christine Nyanzunda dual-role | Documented in Implementation Register | + +--- + +**End of document.** diff --git a/clients/cascades-tucson/docs/security/termination-procedures.md b/clients/cascades-tucson/docs/security/termination-procedures.md new file mode 100644 index 0000000..910b0b8 --- /dev/null +++ b/clients/cascades-tucson/docs/security/termination-procedures.md @@ -0,0 +1,95 @@ +# Cascades of Tucson — Workforce Termination Procedures + +**Built:** 2026-04-24 by Howard (ClaudeTools session) — closes Track B B4 in `PLAN-AND-QUESTIONS-2026-04-24.md` +**Owner:** Security Official (Mike Swanson / Howard Enos) + CE leadership (Meredith Kuhn) +**Review cycle:** Annual, or when a named system changes +**HIPAA reference:** 45 CFR §164.308(a)(3)(ii)(C) Termination Procedures (Required) + §164.316(b)(2) Documentation Retention (Required, 6 years — Cascades posture: 7 years) + +--- + +## Policy statement + +When a Cascades workforce member separates (voluntary or involuntary), their access to ePHI and Cascades systems must be **promptly revoked**, and their employment-period records must be **preserved for at least 7 years** from the date of their last activity or creation (whichever is later). No workforce member's mail, file-share presence, or audit trail may be destroyed prior to the end of the retention clock. + +--- + +## Why 7 years (HIPAA + 1) + +HIPAA §164.316(b)(2) requires 6 years minimum. Cascades adopts 7 years to (a) buffer against state-law retention overlays (AZ medical records = 7 years post-last-encounter), (b) accommodate civil statute-of-limitations carry-over, and (c) provide a safety margin before any irreversible destruction. + +--- + +## Procedure — at termination + +Follow this sequence on the last day of work (or as soon as termination is confirmed for involuntary cases): + +### Step 1 — Disable sign-in (day-of) + +- **Active Directory:** Disable user account (`Disable-ADAccount -Identity `). Move to `OU=Excluded-From-Sync` if they were previously synced, so Entra Connect drops the hybrid mapping. +- **Microsoft 365:** Block sign-in (`Set-MsolUser -UserPrincipalName -BlockCredential $true` or equivalent Graph call). Revoke active sessions (`Revoke-MgUserSignInSession`). +- **ALIS:** In ALIS admin, disable staff profile. If they were linked via Entra SSO, the SSO tie is severed automatically when their M365 sign-in is blocked, but the ALIS staff record stays for audit. +- **File shares / VPN / ScreenConnect / anything else:** Revoke per the access matrix in `docs/security/implementation-register.md`. +- **Remove from distribution groups, shared-mailbox delegations, shared-phone MSDM roster.** + +### Step 2 — Preserve (within 24 hours) + +- **M365 mailbox:** Convert to **Shared Mailbox** (`Set-Mailbox -Identity -Type Shared`). Shared mailboxes do **not** require a license under 50 GB and are not at risk of default-retention deletion. +- **Remove M365 licenses** after shared-mailbox conversion. Free the seat. +- **Apply Litigation Hold** if the tenant has Exchange Online Plan 2 (comes with Business Premium): + - `Set-Mailbox -Identity -LitigationHoldEnabled $true -LitigationHoldDuration 2557 -LitigationHoldDate (Get-Date)` + - 2557 days = 7 years. + - Cascades currently on Business Standard → Litigation Hold **not available** until tenant-wide Business Premium purchase (see Q21 in master plan). Interim posture: shared-mailbox conversion + zero deletion = functionally preserves records under default MRM retention. +- **Hide from Global Address List** (`Set-Mailbox -HiddenFromAddressListsEnabled $true`). Active staff shouldn't see former-employee addresses in autocomplete. +- **Configure forwarding** to successor(s) if there is ongoing external correspondence (vendor invoices, client relationships). Forwarding does NOT satisfy retention on its own — the original mailbox must still exist. + +### Step 3 — Document (within 7 days) + +- **Update the employee record** in Cascades HR with termination date, reason (voluntary/involuntary), access revocation confirmation, mailbox preservation status. +- **Entry in `docs/issues/log.md`** or termination ledger: user, date, systems cleaned, who performed the work. +- **Add to the 7-year retention tracker** (spreadsheet or doc listing preserved mailboxes + deletion-eligible date): `retention-eligible = termination_date + 7 years`. + +### Step 4 — Annual review (every anniversary of their termination) + +- Verify the shared mailbox still exists (no accidental delete) +- Verify Litigation Hold is still enabled (if applicable) and not near expiry +- For employees whose retention window has elapsed: + - Privacy Officer review: any pending subpoena, audit, or litigation? If yes, extend hold. + - If clean: formal decision to either (a) export to offline archive (PST → immutable storage) and then delete, or (b) delete in place. + - Document the destruction decision in the retention tracker. + +--- + +## What NOT to do + +- **Do not delete** a workforce member's M365 user object directly. Deletion puts the mailbox in a 30-day soft-delete window — if not recovered within that window, **all content is permanently destroyed**. For a covered entity handling PHI, that is a §164.316(b)(2) violation and potentially §164.308(a)(1)(ii)(A) Risk Analysis failure to have identified. +- **Do not rely on default MRM retention alone without converting to shared.** A licensed user mailbox whose license is removed can have content auto-deleted by default Exchange policies. Shared mailboxes are safer. +- **Do not allow the 30-day soft-delete window to lapse** after an inadvertent delete — restore and remediate before day 30. +- **Do not skip Step 2 preservation** even for "short-tenure" or "never-logged-in" accounts. If the account existed in production long enough to have any ePHI touch, the retention clock applies. + +--- + +## Incident documentation + +### Incident IR-2026-04-24-001 — Improper deletion of 7 orphan mailboxes + +**What happened:** On 2026-04-22 as part of a pre-Entra-Connect orphan cleanup, 7 M365 user mailboxes were deleted: `ann.dery`, `anna.pitzlin`, `jeff.bristol`, `jodi.ramstack`, `kristiana.dowse`, `nela.durut-azizi`, `nick.pavloff`. The deletion was HR-confirmed at the time but **did not follow the preservation-first procedure** described above. + +**Why it was wrong:** The 7 mailboxes contained (or plausibly contained, given their roles) ePHI or operationally-relevant correspondence. Deleting them without Litigation Hold, retention policy, or shared-mailbox conversion placed them at risk of permanent destruction at day 30. + +**Recovery:** On 2026-04-24 at day 2 of the 30-day soft-delete window, all 7 were restored via Graph API (`Restore-MgDirectoryDeletedItem`). Evidence: `reports/2026-04-24-jeff-restore-ashley-access.md` and follow-on retention report. + +**Post-recovery actions (in progress at time of writing):** Convert each to shared mailbox, remove Jodi Ramstack's unnecessary Business Standard license ($12.50/mo recurring), hide all from Global Address List, place on Litigation Hold when Business Premium is live, enroll all 7 in the 7-year retention tracker with source-date = their original 2026-04-22 deletion date. + +**Preventive control:** This document (`termination-procedures.md`) and training on it. Future orphan cleanups must follow the preservation-first procedure. + +**Signed-off:** [Security Official signature + date] / [CE leadership signature + date] + +--- + +## References + +- `PLAN-AND-QUESTIONS-2026-04-24.md` Track B (B4) +- `docs/security/hipaa-review-2026-04-22.md` +- `docs/security/risk-analysis-2026-04.md` +- `reports/2026-04-22-m365-orphan-deletes.md` (the flawed action this doc remediates) +- `reports/2026-04-24-jeff-restore-ashley-access.md` + follow-on retention report diff --git a/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 115936.png b/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 115936.png new file mode 100644 index 0000000..582713f Binary files /dev/null and b/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 115936.png differ diff --git a/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 115949.png b/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 115949.png new file mode 100644 index 0000000..33ad0b0 Binary files /dev/null and b/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 115949.png differ diff --git a/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 120004.png b/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 120004.png new file mode 100644 index 0000000..e791831 Binary files /dev/null and b/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 120004.png differ diff --git a/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 120020.png b/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 120020.png new file mode 100644 index 0000000..f92f772 Binary files /dev/null and b/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 120020.png differ diff --git a/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 141248.png b/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 141248.png new file mode 100644 index 0000000..f1818b4 Binary files /dev/null and b/clients/cascades-tucson/docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 141248.png differ diff --git a/clients/cascades-tucson/docs/servers/fax-whitelabel.md b/clients/cascades-tucson/docs/servers/fax-whitelabel.md new file mode 100644 index 0000000..8773978 --- /dev/null +++ b/clients/cascades-tucson/docs/servers/fax-whitelabel.md @@ -0,0 +1,76 @@ +# Cascades Fax Architecture — PacketDial WhiteLabel + +**Captured:** 2026-04-24 by Howard +**Screenshots:** `docs/servers/fax-packetdial-whitelabel/` + +## Upstream provider: PacketDial (WhiteLabel aka WL) + +- **Dashboard:** https://voip.packetdial.com/ +- **Account:** `28598` ("CASCADES OF TUCSON" per footer) +- **Platform:** PacketDial v5.17 hosted VoIP + eFax service (private-label reseller of VoIP infra, hence "WhiteLabel") +- **Admin contact:** `CS` login (Cascades admin account — whoever logs in from the MSP side) + +## The three Cascades fax boxes + +Each fax box receives inbound faxes from a PSTN number, then emails the fax as an attachment to a specified M365 address. + +| Box name | Inbound DID | Caller ID | Routes inbound fax to (email) | Faxbox domain | +|---|---|---|---|---| +| **Med Tech** | (520) 347-8490 | "CASCADES" | `medtech@cascadestucson.com` | `medtech.faxboxes.com` | +| **Nurses/RCC** | (520) 347-8460 | "CASCADES" | `fax@cascadestucson.com` | `nurses.faxboxes.com` | +| **Sales** | (520) 347-8449 | "CASCADES" | `crystal.rodriguez@cascad...` (truncated in screenshot) | `ctsales.faxboxes.com` | + +All three: Outbound Faxing = Enabled, Retries on fail = 1, Sent Receipts = On, Timezone = Mountain (w/o DST), Allowed Senders = `@cascadestucson.c...` (any internal user). + +## Inbound flow for the `fax@` mailbox (Nurses/RCC line) + +``` +PSTN fax → (520) 347-8460 → PacketDial "Nurses/RCC" fax box + → email delivery to fax@cascadestucson.com + → Exchange Transport Rule "Fax Forward and Retain Copy" (Priority 0, Enabled) + → BCC to 9 recipients (as of 2026-04-24): + - anna.pitzlin@ [BROKEN — account deleted 2026-04-22, NDRs on every fax] + - christina.dupras@ + - veronica.feller@ + - medtech@ + - karen.rossini@ + - lois.lane@ + - christine.nyanzunda@ + - ashley.jensen@ + - Britney.Thompson@ [will break post-Litigation Hold + disable] +``` + +## Known issues (2026-04-24) + +| Issue | Impact | Action | +|---|---|---| +| Anna Pitzlin in BCC list but mailbox deleted 2026-04-22 | Every fax generates silent NDR for Anna | Remove from rule immediately | +| Britney Thompson in BCC list, scheduled for disable post-Litigation Hold | Will break future faxes once she's disabled | Remove before disabling her | +| Ashley Jensen reports lost access to `fax@` mailbox | She is in BCC list so receives copies, but may have lost direct delegate/FullAccess on the `fax@` shared mailbox — separate from BCC | Grant Ashley FullAccess on `fax@` shared mailbox directly | +| Transport rule model is brittle — every staff change requires rule edit | Operational debt | Refactor: grant FullAccess on `fax@` shared mailbox to all 9 BCC recipients, delete the transport rule entirely, users open `fax@` as secondary mailbox in Outlook | +| Sales fax → crystal.rodriguez@ (single person, no redundancy) | If Crystal leaves or is OOO, faxes go unseen | Consider a shared mailbox for sales faxes too | +| Med Tech fax → medtech@ role mailbox | Current role-mailbox model is under G2 conversion review per master plan | When G2 converts medtech@ to shared, the fax routing continues to work (emails still land in the mailbox) | + +## Outbound faxing + +- Allowed senders: anyone with an `@cascadestucson.com` address can send via the PacketDial relay +- Outbound path not documented in screenshots — presumably SMTP relay from Exchange Online to PacketDial's ingress with Allowed Senders enforcement + +## Access to PacketDial admin + +Login path not yet vaulted. TODO: add PacketDial admin creds to vault at `clients/cascades-tucson/packetdial-whitelabel.sops.yaml` next time we need to change a fax box config. + +## Screenshots (source of truth as of 2026-04-24) + +- `fax-packetdial-whitelabel/Screenshot 2026-04-24 115936.png` — Fax Boxes list (3 boxes) +- `fax-packetdial-whitelabel/Screenshot 2026-04-24 115949.png` — Edit Fax: Med Tech +- `fax-packetdial-whitelabel/Screenshot 2026-04-24 120004.png` — Edit Fax: Nurses/RCC (feeds `fax@`) +- `fax-packetdial-whitelabel/Screenshot 2026-04-24 120020.png` — Edit Fax: Sales + +Exchange transport rule screenshot is in the same directory as the rule definition reference. + +## Related + +- Master plan: `PLAN-AND-QUESTIONS-2026-04-24.md` (Track C — role mailbox conversions G2) +- Orphan deletes: `reports/2026-04-22-m365-orphan-deletes.md` +- Broader M365 context: `docs/cloud/m365.md` diff --git a/clients/cascades-tucson/reports/2026-04-24-jeff-restore-ashley-access.md b/clients/cascades-tucson/reports/2026-04-24-jeff-restore-ashley-access.md new file mode 100644 index 0000000..57ba2c3 --- /dev/null +++ b/clients/cascades-tucson/reports/2026-04-24-jeff-restore-ashley-access.md @@ -0,0 +1,133 @@ +# Mailbox restore + retention remediation — 2026-04-24 + +> **Scope expanded 2026-04-24 (same session):** after Jeff's restore succeeded, Howard correctly flagged that NO terminated employee mailbox should have been deleted — HIPAA §164.316(b)(2) requires 7-year retention. All 7 mailboxes from the 2026-04-22 orphan cleanup were restored from the 30-day soft-delete bin. See §"Full 7-mailbox retention remediation" below. Policy document: `docs/security/termination-procedures.md`. + +--- + +## Original scope: Jeff Bristol mailbox restore — 2026-04-24 + +## Context + +Ashley Jensen reported to Howard: "I seem to have lost access to Jeff's email and the fax email (efax thing). In your spare time, can you help me get them back??" + +Root cause: on 2026-04-22 we deleted 7 orphan M365 accounts including `jeff.bristol@cascadestucson.com` per HR-confirmed orphan cleanup (`reports/2026-04-22-m365-orphan-deletes.md`). Ashley had delegate access to Jeff's mailbox — her access vanished with the delete. + +## Decision + +Howard authorized 2026-04-24: restore Jeff, convert to shared mailbox, grant Ashley Full Access + Send As. Net outcome = Ashley regains access with no license cost. + +Howard's directive: the fax mailbox (`fax@cascadestucson.com`) is separate and is **NOT** to be touched by me (Claude) in this session — Howard will audit its permissions and (planned) refactor the transport rule to a shared-mailbox model later. + +## Actions executed + +### Step 1 — Graph restore (User Manager tier) + +- `POST https://graph.microsoft.com/v1.0/directory/deletedItems/8ec8248a-46e8-4771-9220-047887928777/restore` +- HTTP 200 — restore succeeded +- Post-restore verification via `GET /users/{id}`: + - `displayName`: "Jeff Bristol" + - `userPrincipalName`: `jeff.bristol@cascadestucson.com` (UPN correctly restored) + - `accountEnabled`: `false` (matches pre-delete disabled state) + - `mail`: `jeff.bristol@cascadestucson.com` + - `assignedLicenses`: `[]` (no licenses — expected; will convert to shared mailbox which needs none) + +### Step 2+ — Exchange Online writes — **DEFERRED** + +Exchange REST `POST /adminapi/beta/{tenant}/InvokeCommand` returned **HTTP 401 `invalid_token`** for both `Get-Mailbox jeff.bristol@...` and `Get-Mailbox ashley.jensen@...` (sanity check). + +Token inspection showed valid token state: +- `aud`: `https://outlook.office365.com` (correct) +- `roles`: `full_access_as_app` +- `wids`: includes `29232cdf-9323-42fd-ade2-1d097af3e4de` (Exchange Administrator) + +Diagnosis: the Exchange Administrator directory role was just assigned to the Security Investigator SP (`c64ee5c1-a607-46cb-81b8-42de3de98d48`) by `onboard-tenant.sh` minutes prior. Exchange Online RBAC propagation typically takes 30–60 minutes (sometimes hours) after a fresh role assignment before the SP's token is honored for cmdlet execution. + +Tenant-wide issue (not Jeff-specific): the sanity check against an unrelated mailbox (`ashley.jensen@`) returned the same 401. + +### Step 2+ — Handed off to Howard (manual in Exchange Admin Center) + +Because Ashley needs access now and Exchange RBAC was still propagating, Howard took the portal path directly. Revised scope per Howard 2026-04-24: **FullAccess only, no Send As** (Ashley only needs read). + +Howard's portal work (confirmed 2026-04-24): +1. Recipients → Mailboxes → Jeff Bristol → **Convert to Shared** — pending automated step at 15:13 PDT cron retry (if RBAC propagated) or Howard later +2. Delegation confirmed by Howard: Ashley already had both **Read and manage (Full Access)** AND **Send As** on Jeff's mailbox — left as-is per Howard's direction 2026-04-24 ("she is already set to read and send as jeff, that is fine. we will leave it as is"). The earlier "FullAccess only, no Send As" instruction is superseded. +3. Ashley adds shared mailbox in Outlook: File → Account Settings → More Settings → Advanced → Add → `jeff.bristol@cascadestucson.com` (or OWA at `outlook.office.com/mail/jeff.bristol@cascadestucson.com`) + +### Fax@ mailbox state (captured by Howard's screenshot 2026-04-24 14:12) + +Pulled by Howard in Exchange Admin Center: + +| Property | Value | +|---|---| +| Type | **Shared Mailbox** (display name "Fax Cascades") | +| Send as delegates | **0** | +| Read and manage (Full Access) delegates | **0** | + +Zero pre-existing delegations. Ashley's "lost access to fax email" was not loss of a delegate grant — her access was chained through Jeff's mailbox or some other indirect path that broke when Jeff was deleted. + +Screenshot: `docs/servers/fax-packetdial-whitelabel/Screenshot 2026-04-24 141248.png` (copied into repo separately if needed for future reference). + +### Transport rule — fixed by Howard + +Howard removed the broken recipients from `Fax Forward and Retain Copy` transport rule (2026-04-24). Anna Pitzlin no longer in the BCC list; silent NDR-on-every-fax problem eliminated. + +## Related / follow-ups + +- **Britney Thompson** is still in the rule's BCC list and is scheduled for disable post-Litigation Hold — remove before her disable to avoid the same NDR issue. +- **Proposed refactor (per master plan Track C):** replace the transport rule entirely with direct FullAccess permissions on the `fax@` shared mailbox for the 9 legitimate recipients. Each user opens `fax@` as a secondary mailbox in Outlook. Cleaner audit trail, no rule maintenance on staff changes. Because fax@ currently has zero delegates, this refactor starts from a clean slate. +- **Exchange RBAC propagation:** was still incomplete at time of this session. Next remediation-tool invocation (>1h later or next day) should be able to use `investigator-exo` tier for Exchange REST writes against Cascades. + +## Files + +- Graph restore response: `/tmp/remediation-tool/207fa277-e9d8-4eb7-ada1-1064d2221498/jeff-restore/restore-resp.json` +- Post-restore user check: `/tmp/remediation-tool/.../jeff-restore/user-check.json` +- Fax architecture doc: `docs/servers/fax-whitelabel.md` (written same session) +- Original deletion record: `reports/2026-04-22-m365-orphan-deletes.md` + +--- + +## Full 7-mailbox retention remediation (same session, expanded scope) + +### Trigger + +Howard 2026-04-24: "in fact we shouldnt delete any email accounts, they should all be set for some kind of retention for the 7 years (hippa+1 year) requirement." + +Applied retroactively to the 6 other mailboxes deleted in the same 2026-04-22 sweep that were still recoverable within the 30-day soft-delete window. + +### Soft-delete bin enumeration + +``` +GET /directory/deletedItems/microsoft.graph.user +``` + +8 items returned. 2 were excluded from restoration: +- `mdm@cascadestucson.com` (failed service account replaced by `mdms@` 2026-04-20 — no PHI) +- `howard_azcomputerguru.com#EXT#@NETORGFT4257522.onmicrosoft.com` (Howard's own external guest — no Cascades PHI, intentional delete) + +### Restorations (Graph User Manager tier) + +All 6 returned HTTP 200: + +| User | Object ID | Pre-delete state | Post-restore state | +|---|---|---|---| +| ann.dery | `103b3ac4-2302-4334-8c8e-e66d383c883d` | Disabled, 0 lic | Disabled, 0 lic | +| anna.pitzlin | `06aa2955-f124-447d-8a16-cc7779aaf28f` | Disabled, 0 lic | Disabled, 0 lic | +| kristiana.dowse | `0c501281-3e80-48e0-8a3f-e460a15df470` | Disabled, 0 lic | Disabled, 0 lic | +| nela.durut-azizi | `84cef8a2-6988-44ea-bf20-a72fe622750d` | Disabled, 0 lic | Disabled, 0 lic | +| nick.pavloff | `4b46f47a-6c57-477d-bd6d-53f99324aee4` | Disabled, 0 lic | Disabled, 0 lic | +| **jodi.ramstack** | `b7cddbeb-6026-436b-a3aa-67c4be43e3fb` | **Enabled, 1 Business Standard lic** (zombie) | Enabled, 1 lic | + +### Follow-on actions — blocked pending Exchange RBAC propagation + +Exchange REST `Set-Mailbox -Type Shared` et al. returned HTTP 401 (RBAC not yet propagated after onboard-tenant.sh assigned Exchange Administrator role this session). Retries pending. + +For each of the 7 restored mailboxes (6 above + Jeff): +1. `Set-Mailbox -Identity -Type Shared` +2. `Set-Mailbox -Identity -HiddenFromAddressListsEnabled $true` +3. For Jodi specifically: remove the Business Standard license after conversion — recurring $12.50/mo savings +4. Apply Litigation Hold with 2557-day duration **only after** Business Premium purchase (Cascades currently on Business Standard; Litigation Hold is a Plan-2 feature) +5. Add to 7-year retention tracker: source-date = 2026-04-22 (original deletion date), eligible-for-review = 2033-04-22 + +### Policy document + +Written same session: `docs/security/termination-procedures.md` — mandates preservation-first procedure for all future workforce departures and documents this incident (IR-2026-04-24-001) with remediation steps.