×
  •  
  •  

Configuration

9.0 Configuration Management Policy

iDialogs standardizes and automates configuration management through the use of Chef, through AWS OpsWorks and bash scripts as well as documentation of all changes to production systems and networks. Chef automatically configures all iDialogs systems according to established and tested policies, and are used as part of our Disaster Recovery plan and process.

9.1 Applicable Standards

9.1.1 Applicable Standards from the HITRUST Common Security Framework

  • 06 - Configuration Management

9.1.2 Applicable Standards from the HIPAA Security Rule

  • CFR § 164.310(a)(2)(iii) Access Control & Validation Procedures

9.2 Configuration Management Policies

  1. Puppet is used to standardize and automate configuration management.
  2. One-step deployment scripts are used to deploy application software updates to the iDialogs SaaS platform.
  3. No platform software updates are deployed into iDialogs environments without approval of the iDialogs CTO.
  4. No system software and or updates are deployed into the iDialogs environments without approval of the iDialogs CTO, the iDialogs Security Officer, and any other System Administrator responsible for the environments in question.
  5. All changes to production systems, network devices, and firewalls are approved by the iDialogs CTO and iDialogs Security Officer before they are implemented to assure they comply with business and security requirements.
  6. All changes to production systems are tested before they are implemented.
  7. Implementation of approved changes are only performed by authorized personnel who conform to iDialogs policies under the requirements of CFR § 164.310(a)(2)(iii) - Access Control & Validation Procedures.
  8. Tooling to generate an up-to-date inventory of systems, including corresponding architecture diagrams for related products and services, is hosted on GitHub under the iDialogs Organization and are kept private.
    1. All systems are categorized as production, development, and staging to differentiate based on criticality.
    2. The iDialogs Security Officer maintains scripts to generate inventory lists on demand using APIs provided by each cloud provider.
    3. These scripts are used to generate the diagrams and asset lists required by the Risk Assessment phase of iDialogs Risk Management procedures 4.3.1.
    4. After every use of these scripts, the iDialogs Security Officer will verify their accuracy by reconciling their output with recent changes to production systems. The Security Officer will address any discrepancies immediately with changes to the scripts.
    5. Usage of the aforementioned scripts are logged with each step of the script's execution, the user name the script was executed by, and a date and time stamp for when the step was executed/completed.
  9. All front-end functionality (developer dashboards, portals, views, etc.) are separated from back-end (database, application servers, etc.) systems by being deployed on separate servers or containers.  Front-end functionality is compiled, optimized, and deployed to content driven networks (CDNS) such as Rackspace CDN or Amazon S3 Buckets.
  10. All committed code is reviewed using pull requests to assure software code quality and proactively detect potential security issues in development environments prior to deployment to production environments.
  11. iDialogs utilizes development and staging environments that mirror production to assure proper functionality. The homogenization of servers and systems ensures that both major and trivial differences between environments won't affect normal operations.
  12. iDialogs also deploys environments locally using Vagrant in a similar homogeneous manner to assure functionality before moving to development, staging, or production.
  13. All formal change requests require unique ID and authentication.
  14. Clocks are continuously synchronized to an authoritative source across all systems using NTP or a platform-specific equivalent. Modifying time data on systems is restricted.  NTP servers are restricted to either government or official NIST time servers.

9.3 Provisioning Production Systems

  1. Before provisioning any systems, DevOps team members must file a request in the JIRA Deployment Ticket (DT) project.
    1. JIRA access requires authenticated users.
    2. The CTO grants access to the JIRA DT project following the procedures covered in the Access Establishment and Modification section.
  2. The VP Engineering or CTO must approve the provisioning request before any new system can be provisioned.
  3. Once provisioning has been approved, the DevOps team member must configure the new system according to the standard baseline chosen for the system's role.
    1. For Linux systems, this means adding the appropriate Chef configuration file and running basic provisioning operations.
  4. If the system will be used to house production data (ePHI), the DevOps team member must ensure ePHI data is encrypted at rest. For example, if MySQL is used to store ePHI, MySQL at-rest data encryption must be enabled as well as transit encryption.
    1. For systems on AWS, the DevOps team member must add an encrypted Elastic Block Storage (EBS) volume.
  5. Once the system has been provisioned, the DevOps team member must contact the security team to inspect the new system. A member of the security team will verify that the secure baseline has been applied to the new system, including (but not limited to) verifying the following items:
    1. Removal of default users used during provisioning.
    2. Network configuration for system.
    3. Data volume encryption settings.
    4. Host firewall rules.
    5. Intrusion detection and virus scanning software installed or properly provisioned with the security master server.
    6. All items listed below in the operating system-specific subsections below.
  6. Once the security team member has verified the new system is correctly configured, the team member must add that system to the Lynis security scanner configuration and initiate a full Lynis audit.
    1. If a Lynis audit returns an unsatisfactory report, the security team must rectify the issues the scan provides.
  7. The new system may be rotated into production once the CTO and Security Officer verifies all the provisioning steps listed above have been correctly followed and has marked the Issue with the Approved state.


9.3.1 Provisioning Linux Systems

  1. Linux systems have their baseline security configuration applied via Chef. These baseline states cover:
    1. Ensuring that the machine is up-to-date with security patches and is configured to apply patches in accordance with our policies.
    2. Stopping and disabling any unnecessary OS services.
    3. Installing and configuring the OSSEC IDS agent and provisioning it with the OSSEC server.
    4. Configuring 15-minute session inactivity timeouts.
    5. Configuring security groups.
    6. Configuring Security Group rules.
    7. Installing and configuring the ClamAV and Maldet virus scanners. This includes ensuring freshclam is operating in daemon mode.
    8. Installing and configuring the NTP daemon, including ensuring that modifying system time cannot be performed by unprivileged users.
    9. Configuring the SSH service against the security profile established.
    10. Configuring authentication to the centralized LDAP servers (if applicable).
    11. Configuring audit logging as described in the Auditing Policy section.
  2. Any additional Salt states applied to the Linux system must be clearly documented by the ops team member in the DT request by specifying the purpose of the new system.


9.3.3 Provisioning Management Systems

  1. Provisioning management systems such Chef through AWS OpsWorks, LDAP servers, OSSEC/SNORT/ARPWatch/NTP/DNS servers, or VPN appliances follows the same procedure as provisioning a production system.
  2. Critical infrastructure services such as logging, monitoring, LDAP servers, and Domain servers must be configured with the proper security profiles outlined. These configuration profiles have been approved by the CTO and Security Officer to be in accordance with all iDialogs policies, including setting appropriate:
    1. Audit logging requirements.
    2. Password size, strength, and expiration requirements.
    3. Transmission encryption requirements.
    4. Network connectivity timeouts.
    5. Host firewall rules.
  3. Critical infrastructure roles applied to new systems must be clearly documented by the DevOps team member in the appropriate JIRA requests.

9.4 Changing Existing Systems

  1. Subsequent changes to already-provisioned systems are unconditionally handled by one of the following methods:
    1. Changes to Chef configurations.
    2. For configuration changes that cannot be handled by Chef, a bash script will be used and documented using JIRA or Confluence describing exactly what changes will be made and by whom.
  2. Configuration changes to Puppet must be initiated by creating a Merge Request in GitHub.
    1. The DevOps team member will create a feature branch and make their changes on that branch.
    2. The DevOps team member must test their configuration change locally when possible, or on a development sandbox otherwise.
    3. At least one other DevOps team member must review the changes before merging the change into the main branch.
  3. In all cases, before rolling out the change to production, the DevOps team member must file an Issue in the JIRA project describing the change. This Issue must link to the reviewed Merge Request and/or include a link to the script.
  4. Once the request has been approved by the CTO, the DevOps team member may roll out the change into production environments.

9.5 Patch Management Procedures

  1. iDialogs uses automated tooling to ensure systems are up-to-date with the latest security patches. These tools are governed by the YUM package manager and protected using the yum-security plugin to ensure repository integrity.
  2. On CentOS Linux systems, the yum update tool is used to apply security patches in phases.
    1. The security team maintains mirrored snapshots of security patches from the upstream OS vendor.  The repositories for kernel updates are official RHEL repositories and other software is obtained using official REMI, ATOMIC, and EPEL channels.  These mirrors are synchronized bi-weekly and applied to development systems nightly.
    2. If the development systems function properly after a one-week testing period, the security team will promote that snapshot into the mirror used by all staging systems. These patches will be applied to all staging systems during the next nightly patch run.
    3. If the staging systems function properly after a one-week testing period, the security team will promote that snapshot into the mirror used by all production systems. These patches will be applied to all production systems during the next nightly patch run.
    4. 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 such as imminent, zero-day threats.

9.6 Software Development Procedures

  1. All development uses feature branches based on the main branch used for the current release. The iDialogs Organization implements the standard GitFlow for GIT.  Any changes required for a new feature or defect fix are committed to that feature branch.
    1. These changes must be covered under:
      1. A unit test if applicable
      2. Integration tests
    2. Integration tests are required if unit tests cannot reliably exercise all facets of the change.
  2. Developers are strongly encouraged to follow the commit message conventions suggested by GitHub.
    1. Commit messages should be wrapped to 72 characters.
    2. 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.
  3. 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 (if the feat/patch branch is not already named with the corresponding JIRA issue) and should provide a high-level description of the changes made.
  4. 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.
    1. Other engineers will review the changes, using the guidelines above.
    2. 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.
  5. If the feature or defect interacts with ePHI, or controls access to data potentially containing ePHI, the code changes must be reviewed by the Security Officer before the feature is marked as complete.
    1. This review must include a security analysis for potential vulnerabilities such as those listed in the OWASP Top 10.
    2. This review must also verify that any actions performed by authenticated users will generate appropriate audit log entries.
  6. Once the review process finishes, each reviewer should leave a comment on the pull request confirming their review of the pull request.  Once all necessary code reviews and unit/integration tests are completed, either the CTO or the iDialogs Security Officer may merge the pull request into the target branch.

9.7 Software Release Procedures

  1. Software releases are treated as changes to existing systems and thus follow the procedure described in 9.4.