Configuration Management Policy
Praktice AI standardizes and automates configuration management through the use of Docker/Kubernetes scripts as well as documentation of all changes to production systems and networks. Kubernetes-based Docker automatically configures all Praktice AI systems according to established and tested policies.
9.1 Applicable Standards
9.1.1 Applicable Standards from the HIPAA Security Rule
164.310(a)(2)(iii) Access Control & Validation Procedures
9.2 Configuration Management Policies
Kubernetes and Docker are used to standardize and automate configuration management.
No new software systems are deployed into Praktice AI production environments without approval of a Praktice AI Officer. The approval is documented using a unique ticket logged and tracked by JIRA.
All changes to production systems, network devices, and firewalls are reviewed by another developer before they are implemented to assure they comply with business and security requirements.
All changes to production systems are tested before they are implemented in production.
Implementation of approved changes are only performed by authorized personnel.
Inventory of systems, including corresponding architecture diagrams for related products and services, is updated on changes to the system, and stored in a shared Google Drive folder.
After each update, the Security Officer will verify their accuracy by reconciling them with recent changes to production systems. The Security Officer will address any discrepancies immediately with changes to the inventory.
All major system functionality functionality is separated by being deployed on separate containers.
All software and systems are monitored for security vulnerabilities (as described in §9.5 ), and unit tested where appropriate.
All committed code is reviewed using pull requests to assure software code quality and proactively detect potential security issues in development.
Praktice AI utilizes development and staging environments that mirror production to assure proper function.
Praktice AI also deploys environments locally to assure functionality before moving to staging or production.
All formal change requests require a unique ticket logged, and tracked by JIRA.
When a critical bug on the production system is discovered, the Security Officer or the COO can authorize a hot fix process that allows a designated engineer to modify production systems to fix the discovered bug without going through the above process at the time. Once the bug is fixed, the engineer will document all changes to production systems affected as part of the fix and ensure review by another developer and sign-off by the Security Officer to end the hot fix process. Approval for the hot fix process and documentation is tracked via a unique ticket logged in JIRA. In addition, the results of a root cause analysis of the critical bug will be reviewed together with the engineering team after the ticket was closed.
9.3 Provisioning Production Systems
All hardware provisioning is provided either automatically to respond to scaling demands, or at the approval of a Praktice AI officer.
When new hardware is provisioned automatically, Kubernetes sets the configuration automatically using a secured configuration schema.
All systems are deployed using Docker into Kubernetes pods.
Provisioning new subsystems, and configuration updates must specifically review changes to make sure that:
Only specified ports required for external services are exposed to the public Internet directly;
All systems must use an encrypted block data volume, provisioned by Kubernetes;
All Docker systems within Kubernetes must use an encrypted communication channel for both inbound, and outbound communication.
9.4 Changing Existing Systems
Subsequent changes to already-provisioned systems are unconditionally handled by one of the following methods:
Changes to Kubernetes configuration
Changes to Docker recipes.
Continuous Integration deployment via Travis-CI.
For configuration changes that cannot be handled by Kubernetes or Docker, a runbook describing exactly what changes will be made and by whom.
Configuration changes to Docker recipes or Kubernetes configuration must be initiated by creating a Merge Request in GitHub.
The ops team member will create a feature branch and make their changes on that branch.
The ops team member must test their configuration change on a development and/or staging sandbox.
At least one other ops team member must review the Docker or Kubernetes changes before merging the change into the main branch.
Once the request has been approved, the ops team member may roll out the change into production environments.
9.5 Patch Management Procedures
Praktice AI uses bulletin monitoring, automated vulnerability scanners, and rolling updates to ensure systems are up-to-date with the latest security patches.
For Operating System, and Application updates, rebuilding the Docker images is used to apply security patches in phases:
The devops & security team monitors new disclosures, and availability of security patches from the upstream OS vendors. On Vulnerability disclosure, a new Docker image containing the available patch is built, and deployed to the staging system.
If the staging systems functions properly after a testing period of at least one week, the security team will promote that Docker image into the repository used by all production systems. These patches will be applied to all production systems during the next rolling update.
Patches for critical kernel security vulnerabilities may be applied to production systems using hot-patching tools at the discretion of the Security Officer. These patches must follow the same phased testing process used for non-kernel security patches; this process may be expedited for severe vulnerabilities.
For software modules, and libraries, language-specific vulnerability scanners (Snyk) are used to monitor for vulnerabilities.
All modules, and used libraries are scanned on install, and on a weekly basis, for new disclosed vulnerabilities
Upon vulnerability disclosure, it is the responsibility of the developer to determine severity, and potential impact based on the specific usage of the library, and to either apply updates if available, validate the code path to avoid the specific vulnerability, or to find a suitable alternative for the module.
Library updates, and patches are rolled into staging using the Continuous Integration process described in §9.6.
9.6 Software Development Procedures
All development uses feature branches based on the main branch used for the current release. Any changes required for a new feature or defect fix are committed to that feature branch.
Developers are encouraged to follow the commit message conventions suggested by GitHub.
Commit messages should be wrapped to 72 characters.
Commit messages should be written in the present tense. This convention matches up with commit messages generated by commands like git merge and git revert.
Once the feature and corresponding tests are complete, a pull request will be created using the GitHub web interface. The pull request should indicate which feature or defect is being addressed and should provide a high-level description of the changes made.
Code reviews are performed as part of the pull request procedure. Once a change is ready for review, the author(s) will notify other engineers using an appropriate mechanism, typically via an @channel message in Slack.
Other engineers will review the changes, using the guidelines above.
Engineers should note all potential issues with the code; it is the responsibility of the author(s) to address those issues or explain why they are not applicable.
If the feature or defect interacts with ePHI, or controls access to data potentially containing ePHI, the code review must specifically make sure, that:
No PHI is included in the code
Any actions performed by authenticated users will generate appropriate audit log entries.
Once the review process finishes, the reviewer may merge their change into the release branch.
9.7 Software Release Procedures
Software releases are treated as changes to existing systems and thus follow the procedure described in §9.4.