×
  •  
  •  

System Access

7.0 System Access Policy

Access to iDialogs systems and application is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, consultants, and any other entity, is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized user or access of the iDialogs Organization's information systems.

7.1 Applicable Standards

7.1.1 Applicable Standards from the HITRUST Common Security Framework

  • 01.d - User Password Management
  • 01.f - Password Use
  • 01.r - Password Management System
  • 01.a - Access Control Policy
  • 01.b - User Registration
  • 01.h - Clear Desk and Clear Screen Policy
  • 01.j - User Authentication for External Connections
  • 01.q - User Identification and Authentication
  • 01.v - Information Access Restriction
  • 02.i - Removal of Access Rights
  • 06.e - Prevention of Misuse of Information Assets

7.1.2 Applicable Standards from the HIPAA Security Rule

  • CFR § 164.308a4iiC Access Establishment and Modification
  • CFR § 164.308a3iiB Workforce Clearance Procedures
  • CFR § 164.308a4iiB Access Authorization
  • CFR § 164.312d Person or Entity Authentication
  • CFR § 164.312a2i Unique User Identification
  • CFR § 164.308a5iiD Password Management
  • CFR § 164.312a2iii Automatic Logoff
  • CFR § 164.310b Workstation Use
  • CFR § 164.310c Workstation Security
  • CFR § 164.308a3iiC Termination Procedures

7.2 Access Establishment and Modification

  1. Requests for access to iDialogs Platform systems and applications is made formally using the following process:
    1. The iDialogs workforce member, or their manager, initiates the access request by creating an Issue in the JIRA Compliance Review Activity (CRA) Project.
      1. User identities must be verified prior to granting access to new accounts.
      2. Identity verification must be done in person where possible; for remote employees, identities must be verified over the phone.
      3. For new accounts, the method used to verify the user's identity must be recorded on the JIRA issue.
    2. The Security Officer will grant access to systems as dictated by the employee's job title. If additional access is required outside of the minimum necessary to perform job functions, the requester must include a description of why the additional access is required as part of the access request.
    3. Once the review is completed, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
    4. If the review is approved, the Security Officer then marks the Issue as "Done," adding any pertinent notes required. The Security Officer then grants requested access.
      1. New accounts will be created with a temporary secure password that meets all requirements from 7.2.12, which must be changed on the initial login.  For asymmetric RSA key authentication, users must provide their public key as RSA 4096-bit and confirm their private key is encrypted with a minimum AES 128-bit cipher preferably in  PKCS #8 standard.
      2. All password exchanges must occur over an authenticated channel. All activity on secured systems occurs over a secured VPN tunnel and through encrypted SSH communication channels.
      3. For production systems, access grants are accomplished by adding the appropriate user account to the corresponding security group as is necessary to perform the duties required by the user's job.
      4. For non-production systems, access grants are accomplished by leveraging the access control mechanisms built into those systems. Account management for non-production systems may be delegated to an iDialogs employee at the discretion of the Security Officer.
  2. Access is not granted until receipt, review, and approval by the iDialogs Security Officer
  3. The request for access is retained for future reference.
  4. All access to iDialogs systems and services are reviewed and updated on a bi-annual basis to ensure proper authorizations are in place commensurate with job functions. The process for conducting reviews is outlined below:
    1. The Security Officer initiates the review of user access by creating an Issue in the JIRA Compliance Review Activity (CRA) Project.
    2. The Security Officer, or a Privacy Officer, is assigned to review levels of access for each iDialogs workforce member.
    3. If user access is found during review that is not in line with the least privilege principle, the process below is used to modify user access and notify the user of access changes. Once those steps are completed, the Issue is then reviewed again.
    4. Once the review is completed, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
    5. If the review is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
    6. Review of user access is monitored on a quarterly basis using JIRA reporting to assess compliance with above policy.
  5. Any iDialogs workforce member can request change of access using the process outlined in 7.2.1.
  6. Access to production systems is controlled using centralized user management and authentication.
  7. Temporary accounts are not used unless absolutely necessary for business purposes.
    1. Accounts are reviewed every 90 days to ensure temporary accounts are not left unnecessarily.
    2. Accounts that are inactive for over 90 days are removed.
  8. In the case of non-personal information, such as generic educational content, identification and authentication may not be required. This is the responsibility of iDialogs Customers to define, and not iDialogs.
  9. Privileged users must first access systems using standard, unique user accounts before switching to privileged users and performing privileged tasks.
    1. For production systems, this is enforced by creating non-privileged user accounts that must invoke sudo to perform privileged tasks.
    2. Rights for privileged accounts are granted by the Security Officer using the process outlined in 7.2.1.
  10. All application to application communication using service accounts is restricted and not permitted unless absolutely needed. Automated tools are used to limit account access across applications and systems.
  11. Generic accounts are not allowed on iDialogs systems.
  12. Access is granted through encrypted, VPN tunnels that utilize two-factor authentication.
    1. Two-factor authentication is accomplished using a Time-based One-Time Password (TOTP) as the second factor.
    2. Unique, per-user, 4096-bit asymmetric RSA key-pair for access to network protected systems.
    3. VPN connections use AES 256-bit encryption, or equivalent.
    4. VPN sessions are automatically disconnected after 30 minutes of inactivity.
  13. In cases of increased risk or known attempted unauthorized access, immediate steps are taken by the Security and Privacy Officer to limit access and reduce risk of unauthorized access.
  14. Direct system to system, system to application, and application to application authentication and authorization are limited and controlled to restrict access.

7.3 Workforce Clearance

  1. The level of security assigned to a user to the organization's information systems is based on the minimum necessary amount of data access required to carry out legitimate job responsibilities assigned to a user's job classification and/or to a user needing access to carry out treatment, payment, or healthcare operations.
  2. All access requests are treated on a least-access principle.
  3. iDialogs maintains a minimum necessary approach to access to customer data. As such, iDialogs, including all workforce members, does not readily have access to any ePHI.
  4. If access to customer data is required to perform the duties required by an employee's job, a formal request to the iDialogs Privacy and Security Officers must be made and signed off using the available PHI request documents.

7.4 System Access Authorization

  1. Role based access categories for each iDialogs system and application are pre-approved by the Security Officer or VP of Engineering.
  2. iDialogs utilizes firewalls to segment data, prevent unauthorized access, and monitor traffic for denial of service attacks.
  3. Access requests are automatically logged and reported by system monitoring software for both approvals and denials.
    1. Repeated failed attempts can lead to automated, temporary banning of the offending source IP address and subsequent bans can lead to the suspension of the user account in question.

7.5 Person or Entity Application Authentication

  1. Each workforce member has a unique user ID and policy compliant password that identifies him/her as the user of the information system.
  2. Each Customer and Partner has a unique user ID and policy compliant password that identifies him/her as the user of the information system.
  3. All Customer support desk interactions must be verified before iDialogs support personnel will satisfy any request having information security implications.
    1. iDialogs' current support desk software, Zendesk, requires users to authenticate before submitting support tickets.
    2. Support issues submitted via the iDialogs dashboard require that users authenticate with their iDialogs account before submitting support tickets.
    3. Support issues submitted by email must be verified by iDialogs personnel using a phone number that has been registered with the corresponding account.

7.6 UNIQUE USER IDENTIFICATION

  1. Access to the iDialogs Platform systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
  2. Passwords requirements mandate strong password controls (see 7.11).
  3. Passwords are not displayed at any time and are not transmitted or stored in plain text.
  4. Default accounts on all production systems, including root, are disabled.
  5. Shared accounts are not allowed within iDialogs systems or networks.
  6. Automated log-on configurations that store user passwords or bypass password entry are not permitted for use with iDialogs workstations or production systems.

7.7 AUTOMATIC LOGOFF

  1. Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password protected screen saver or logging off the system).
  2. Information systems automatically log users off the systems after 15 minutes of inactivity.
  3. The Security Officer approves exceptions to automatic log off requirements prior to implementation.

7.8 Employee Workstation Use

All workstations within the iDialogs Organization are company owned and are operating using Mac OS X, Linux, or Windows platforms.

  1. Workstations may not be used to engage in any activity that is illegal or is in violation of iDIalogs policies.
  2. Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene or X-rated. Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individuals race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through system owned by the iDialogs Organization.
  3. Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to the iDialogs' best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval.
  4. Solicitation of non-company business, or any use of iDIalogs' information systems/applications for personal gain is prohibited.
  5. Transmitted messages may not contain material that criticizes the organization, its providers, its employees, or others.
  6. Users may not misrepresent, obscure, suppress, or replace another user's identity in transmitted or stored messages.  Obscuring or suppressing another's user's identity can be authorized by the iDialogs Privacy Officer if absolutely necessary using the Safe Harbor method.
  7. Workstation hard drives will have full-disk encryption enabled using FileVault, BitLocker, or equivalent solution.
  8. All workstations have host-based firewalls enabled to prevent unauthorized access unless explicitly granted.
  9. All workstations are required to run appropriate anti-virus software approved for use by the iDialogs Organization.
  10. Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password protected screen saver or logging off the system).
  11. All workstations are to have the following messages added to the lock screen and login screen: This computer is owned by iDialogs, LLC. By logging in, unlocking, and/or using this computer you acknowledge you have seen and follow the policies outlined in https://www.idialogs.com/help/policies.  Contact: privacy@idialogs.com.
  12. Workstation displays should be private and positioned in a manner which prevents viewing from unintended parties. If such a position is unreasonable or not possible then privacy screen protectors must be utilized.

7.9 Wireless Access Use

  1. iDialogs production systems are not accessible directly over wireless channels.
  2. Wireless access is disabled on all production systems.
  3. Wireless networks managed within iDialogs non-production facilities (offices, etc.) are secured with the following configurations:
    1. All data in transit over wireless is encrypted using WPA2 encryption;
    2. Passwords are rotated on a regular basis, presently quarterly. This process is managed by the iDialogs Security Officer.

7.10 Employee Termination Procedures

  1. The Human Resources Department (or other designated department), users, and their supervisors are required to notify the Security Officer upon completion and/or termination of access needs and facilitating completion of the Termination Checklist.
  2. The Human Resources Department, users, and supervisors are required to notify the Security Officer to terminate a user's access rights if there is evidence or reason to believe the following (these incidents are also reported on an incident report and is filed with the Privacy Officer):
    1. The user has been using their access rights inappropriately;
    2. A user's password has been compromised (a new password may be provided to the user if the user is not identified as the individual compromising the original password);
    3. An unauthorized individual is utilizing a user's User Login ID and password (a new password may be provided to the user if the user is not identified as providing the unauthorized individual with the User Login ID and password).
  3. The Security Officer will terminate users' access rights immediately upon notification, and will coordinate with the appropriate iDialogs employees to terminate access to any non-production systems managed by those employees.
  4. The Security Officer audits and may terminate access of users that have not logged into iDialogs' information systems/applications for an extended period of time.

7.11 Paper Records

iDialogs does not use paper records for any sensitive information. Use of paper for recording and storing sensitive data is against iDialogs policies.

7.12 Password Management

  1. User IDs and passwords are used to control access to iDialogs systems and may not be disclosed to anyone for any reason.
  2. Users may not allow anyone, for any reason, to have access to any information system using another user's unique user ID and password.
  3. On all production systems and applications in the iDialogs environment, password configurations are set to require:
    1. A minimum length of 8 characters
    2. A mix of upper case characters, lower case characters, at least one number or special characters
    3. A 90-day password expiration, or 60-day password expiration for administrative accounts
    4. prevention of password reuse using a history of the last 6 passwords
    5. where supported, modifying at least 4 characters when changing passwords
    6. account lockout after 5 invalid attempts
  4. All system and application passwords must be stored and transmitted securely.
    1. Where possible, passwords should be stored in a hashed format using a salted cryptographic hash function (SHA-256 or equivalent)
    2. Passwords that must be stored in non-hashed format must be encrypted at rest pursuant to the requirements in 17.8
    3. Transmitted passwords must be encrypted in flight pursuant to the requirements in 17.9
  5. Each information system automatically requires users to change passwords at a pre-determined interval as determined by the organization, based on the criticality and sensitivity of the ePHI contained within the network, system, application, and/or database.
  6. Passwords are inactivated immediately upon an employee's termination (refer to the Employee Termination Procedures in 7.10).
  7. All default system, application, and Partner passwords are changed before deployment to production.
  8. Upon initial login, users must change any passwords that were automatically generated for them.
  9. Password change methods must use a confirmation method to correct for user input errors.
  10. All passwords used in configuration scripts are secured and encrypted.
  11. If a user believes their user ID has been compromised, they are required to immediately report the incident to the Security Office.
  12. In cases where a user has forgotten their password, the following procedure is used to reset the password.
    1. The user submits a password reset request using an online form accessible via a "Forgot Password" link.
    2. The system will send an email to the email provided if an account with the provided email exists. The system will not provide differentiated copy in response to a password reset request regardless of if an account associated with the provided email exists.
    3. If the account does exist, the user can check their email inbox for an iDialogs Password Reset Email which will provide a unique, one-time URL to a password reset form which can be used to reset the password of the account.
    4. The user can then enter an verify a new password for their account.
  13. For employees who have forgotten passwords or have lost access to private RSA keys, they can submit a formal request to the iDialogs Security Officer to reset a password for them or replace a public RSA authentication key if needed.

7.13 Access to ePHI

  1. Employees may not download ePHI to any workstations used to connect to production systems.
  2. Disallowing transfer of ePHI to workstations is enforced through technical measures.
    1. All production access to systems is performed through a bastion/jump host accessed through a VPN. Direct access to production systems is disallowed by iDialogs' VPN configuration.
    2. On production servers, all transfer services are restricted to the root user including file-transfer functionality of SSH services (SCP/SFTP).
    3. Configuration settings for enforcing these technical controls are managed by iDialogs' configuration management tooling.

7.14 Documentation Requirements

The following outlines the responsibilities which fall outside the purview of Rackspace and within the scope of the iDialogs Organization:

  1. Network logs of activity occurring outside of normal operation unknown to the system including:
    1. Intranet traffic packet anomalies
    2. New host detection
    3. Missing host detection
  2. Firewall and VPN access and error logs including:
    1. Employee remote access via VPN and SSH logged for both failure and acceptance
    2. All unknown source access  access/denials with IP addresses
    3. Intrusion detection analysis logs from platform Intrusion Detection Systems
  3. Host-based integrity checking logs for anomalies in regards to file changes and integrity including
    1. File creation/modification/deletion
    2. File integrity monitoring logs