Access control

MedStack Confidential

Metadata

responsible officer: CTO
approved by: CTO
date
- effective: 2018-06-20
- revised: 2022-08-31
- reviewed: 2022-08-31
Applicability: standard

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.

Code	Section	Title
ISO	A.9.4.1	Information access restriction
ISO	A.9.2.4	Management of secret authentication information of users
HIPAA	164.308(a)(4)(ii)(C)	Access establishment and modification (Addressable)

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.

Code	Section	Title
ISO	A.9.1.2	Access to networks and network services
ISO	A.9.2.1	User registration and de-registration
ISO	A.9.2.2	User access provisioning
ISO	A.9.2.3	Management of privileged access rights
ISO	A.9.2.6	Removal or adjustment of access rights
CHI	SR60	Timely Revocation of Access Privileges
HIPAA	164.308(a)(4)(ii)(B)	Access authorization (Addressable)

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).

Code	Section	Title
ISO	A.9.3.1	Use of secret authentication information
ISO	A.9.4.3	Password management system
HIPAA	164.308(a)(5)(ii)(D)	Password management (Addressable)

Code	Section	Title
ISO	A.9.4.2	Secure log-on procedures
HIPAA	164.312(a)(2)(iii)	Automatic logoff (Addressable)
HIPAA	164.312(d)	Standard: Person or entity authentication
SOC2	CC6.1	The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.
SOC2	CC6.1	The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.
SOC2	CC6.6	The entity implements logical access security measures to protect against threats from sources outside its system boundaries.

Code	Section	Title
ISO	A.9.4.4	Use of privileged utility programs
CHI	SR68	Controlling Access to EHRi System Utilities

Code	Section	Title
ISO	A.9.2.5	Review of user access rights
CHI	SR56	Reviewing User Registration Details
SOC2	CC6.2	Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.

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).

Code	Section	Title
HIPAA	164.312(a)(2)(i)	Unique user identification (Required)

Code	Section	Title
ISO	A.9	Access control
ISO	A.9.1	Business requirements for access control
ISO	A.9.1.1	Access control policy
ISO	A.9.2	User access management
ISO	A.9.3	User responsibilities
ISO	A.9.4	System and application access control
HIPAA	164.308(a)(4)(i)	Standard: Information access management
HIPAA	164.308(a)(4)(ii)(A)	Isolating health care clearinghouse functions (Required)
HIPAA	164.312(a)	Standard: Access control
SOC2	CC6.1	The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.
SOC2	CC6.1	The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.