Policies, Agreements, Terms & Conditions
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.
- Limitations on our management of customer systems
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 |
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.
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 establishment and modification |
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).
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 |
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).
- Require two-factor authentication
Code | Section | Title |
---|---|---|
ISO | A.9.4.2 | Secure log-on procedures |
HIPAA | 164.312(a)(2)(iii) | Automatic logoff |
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. |
Restrict use of admin utilities
Code | Section | Title |
---|---|---|
ISO | A.9.4.4 | Use of privileged utility programs |
CHI | SR68 | Controlling Access to EHRi System Utilities |
Review access grants quarterly
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. |
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).
Code | Section | Title |
---|---|---|
HIPAA | 164.312(a)(2)(i) | Unique user identification |
Enforcement
- Responsible party: All managers and supervisors
- sanctions: standard
References
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) | Information access management |
HIPAA | 164.312(a) | 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. |
Life Support Mental Health Inc. @ 2022
All Rights Reserved