Vendor Remote Access and Flat-Network PACS
A property management firm operates PACS at three sites: 18 controllers, 140 doors, 2,000 cardholders, and one PACS server at headquarters. The server runs an end-of-support operating system. The integrator uses a shared admin account and an internet-facing remote desktop gateway to support all three sites. Two controllers still have the manufacturer default password, firmware is four years old, and PACS logs are retained only 30 days on local disk. A recent penetration test found that the PACS VLAN is reachable from the guest Wi-Fi. The firm wants to add mobile credentials and a cloud API for tenant self-service within six months. Staff have not received security-awareness training, and there is no tested PACS incident-response plan. The firm has a SIEM but does not collect PACS logs.
1. Prioritize cybersecurity remediation before the mobile-credential and cloud-API rollout.
Read the worked answer
Fix identity and exposure before adding mobile or cloud. The highest-risk items are the internet-facing remote desktop gateway, the shared admin account, default controller passwords, and the guest-Wi-Fi path to the PACS VLAN. Start by removing direct internet exposure, disabling default accounts, setting unique credentials, and restricting the PACS VLAN to required hosts. Then address the end-of-support server, because unsupported systems cannot be reliably patched; plan an upgrade or migration. Update controller firmware after a compatibility check and backup. Enable logging to the SIEM with time synchronization, and retain logs longer than 30 days. Mobile credentials and a cloud API expand the attack surface, so require MFA, device binding, API authentication, rate limiting, and a data-flow review before pilot. Do not treat the PACS as an isolated system; it shares identity data and often vendor access with IT.
2. Design secure remote access and network segmentation for the integrator and the future cloud API.
Read the worked answer
Segment the PACS into a security VLAN with a firewall policy that allows only the head-end, controllers, and required management hosts to communicate. Remove guest-Wi-Fi reachability; guests should not route to PACS at all. For vendor support, use a jump host with MFA, unique named accounts, session recording, and time-bound access; no shared admin. Prefer outbound-initiated remote support from the vendor to a broker rather than inbound open ports. Put the PACS server behind the firewall, restrict management to an admin VLAN, and log all firewall denies. For the cloud API, use TLS, strong authentication, scoped tokens, and a gateway that does not expose controllers directly. Test the rules with a penetration test or configuration review. Document the data flows for cardholder photos and access records, because moving to cloud changes privacy and retention obligations.
3. Build the monitoring and incident-response plan for PACS, including what to log and how to rehearse.
Read the worked answer
Build a PACS-specific incident-response playbook: who can declare an incident, how to isolate a controller or server, how to fail over to offline mode, how to preserve logs, and how to notify tenants and law enforcement if needed. Collect PACS logs into the SIEM and alert on repeated failed logins, after-hours admin changes, disabled alarms, default-account use, and unusual badge access. Rehearse a ransomware or vendor-compromise scenario, including manual door control and credential revocation. Keep offline backups of PACS configuration and test restoration. For the mobile and cloud rollout, define monitoring for API abuse and lost devices. After any incident, review door access logs and video together; PACS logs alone may not show who tailgated. Assign an owner for the plan and review it at least annually.