MedStack Technology Compliance Policies

Access control

Automate access control management for access

• by us, to
  • PHI
  • servers, programs, processes, networks, etc.
  • administrative functions
  • facilities (where possible)
  • equipment (where possible)
• by customers
  • Limitations on our management of customer systems
    • Administrative access for customers means access to administrative functions on the systems we operate for them.
    • We only manage customer administrative access and no other type of access related to the customer.
    • For example, we do not manage, monitor, access, or otherwise involve ourselves in any other access to customer apps, database schemas or data, files, cache data, point of services, electronic health record systems, or any other customer systems or data.
  • Customer administrative authorization and access
    • Provide customers with a secure method to establish, modify and terminate authorization for access.

Grant, modify, and terminate user access

• Grant access
  • in sync with authorization grants
  • no more than necessary to implement the authorization
• Modify access control grants
  • when authorization changes.
• Terminate access
  • immediately when authorization terminates
  • independently of the technology used for access
• Review access
  • immediately when a user’s role or authorization changes
  • quarterly for all users
• Use the principle of least privilege
  • Run customer applications on low-privilege accounts with restricted system access.

Secret authentication information

• Create strong passphrases (passwords)
  • The user creates their own passphrase, subject to the minimum standards by the service (such as Google Suite).
  • Encourage users to use password management tools and generate random passphrases.
• Evaluate passphrase strength using entropy
  • Minimum lengths and requirements to use certain types of characters do not reliably increase the difficulty of guessing a passphrase.
  • Minimum recommended entropy for interactive login systems is 40 bits.
• Generate strong secret keys
  • The user creates their own key using an authorized key-generation tool (such as OpenSSH).
  • A key is generated for the user and provided to them through a secure encrypted channel (such as customer credentials).
  • The key strength for SSH keys is at least 2048-bits.
  • Document the allocation and transfer to users.
• Do not require scheduled passphrase rotation
  • Password rotation introduces weaknesses such as password hashing vulnerabilities and the use of easily guessable passwords.
• Rotate secret authentication information as required
  • Change affected secrets in the event of an information security compromise.
• Storage of passwords in writing
  • Important passwords may be stored in writing on paper.
  • The paper copy must be kept out of sight (such as in a drawer).

Logging in and out

• Require authentication with a username and a strong passphrase (or secret key) on all systems.
  • Require two-factor authentication
    • For access to the MedStack Dashboard
    • For access to vendor systems, where feasible
  • Automatic logoff
    • Enable in vendor services where available.
    • Enable on workstations where available.
    • Do not enable in situations where it would have no effect because login is automated (such as SSH).

Restrict use of admin utilities

Review access grants quarterly

Unique user IDs

• Exclusively use unique user IDs for information system access and activities where possible.
• Do not require UUIDs where it would make it impossible to automate key tasks (for example, API keys for access between CI/CD systems).

Enforcement

• Responsible party: All managers and supervisors
• sanctions: standard

References