8.0 Auditing Policy

iDialogs shall audit access and activity of electronic protected health information (ePHI) applications and systems in order to ensure compliance. The Security Rule requires healthcare organizations to implement reasonable hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Audit activities may be limited by application, system, and/or network auditing capabilities and resources. iDialogs shall make reasonable and good-faith efforts to safeguard information privacy and security through a well-thought-out approach to auditing that is consistent with available resources.

It is the policy of iDialogs to safeguard the confidentiality, integrity, and availability of applications, systems, and networks. To ensure that appropriate safeguards are in place and effective, iDialogs shall audit access and activity to detect, report, and guard against:

  • Network vulnerabilities and intrusions
  • Breaches in confidentiality and security of patient protected health information
  • Performance problems and flaws in applications
  • Improper alteration or destruction of ePHI
  • Out of date software and/or software known to have vulnerabilities.

This policy applies to all iDialogs Add-on systems, including BaaS, that store, transmit, or process ePHI.

8.1 Applicable Standards

8.1.1 Applicable Standards from the HITRUST Common Security Framework

  • 0.a Information Security Management Program
  • 01.a Access Control Policy
  • 01.b User Registration
  • 01.c Privilege Management
  • 09.aa Audit Logging
  • 09.ac Protection of Log Information
  • 09.ab - Monitoring System Use
  • 06.e - Prevention of Misuse of Information

8.1.2 Applicable Standards from the HIPAA Security Rule

  • CFR § 164.308(a)(1)(ii)(D) - Information System Activity Review
  • CFR § 164.308(a)(5)(ii)(B) & (C) - Protection from Malicious Software & Log-in Monitoring
  • CFR § 164.308(a)(2) - HIPAA Security Rule Periodic Evaluation
  • CFR § 164.312(b) - Audit Controls
  • CFR § 164.312(c)(2) - Mechanism to Authenticate ePHI
  • CFR § 164.312(e)(2)(i) - Integrity Controls

8.2 Auditing Policies

  1. Responsibility for auditing information system access and activity is delegated to iDialogs Security Officer. The Security Officer shall:
    1. Assign the task of generating reports for audit activities to the workforce member responsible for the application, system, or network.
    2. Assign the task of reviewing the audit reports to the workforce member responsible for the application, system, or network, the Privacy Officer, or any other individual determined to be appropriate for the task.
    3. Organize and provide oversight to a team structure charged with audit compliance activities (e.g., parameters, frequency, sample sizes, report formats, evaluation, follow-up, etc.).
    4. All connections to the iDialogs Organization's systems are monitored. Access is limited to certain services, ports, and destinations. Exceptions to these rules, if created, are reviewed on an annual basis and must be approved by the iDialogs Security Officer.
  2. The iDialogs Organization's auditing processes shall address access and activity at the following levels listed below. The auditing processes may address date and time of each log-on attempt, date and time of each log-off attempt, devices used, functions performed, etc.
    1. User: User level audit trails generally monitor and log commands directly initiated by the user, identification and authentication attempts, and files and resources accessed.
    2. Application: Application level audit trails generally monitor and log user activities, including data files opened and closed, specific actions, and printing reports.
    3. System: System level audit trails generally monitor and log user activities, applications accessed, and other system defined specific actions.
    4. Network: Network level audit trails generally monitor information on what is operating, penetrations, and vulnerabilities.
  3. The Security Officer is responsible for ensuring that the iDialogs Organization logs all incoming and outgoing traffic to into and out of its environment. This includes all successful and failed attempts at data access and editing. Metadata and other such data associated with this information will include origin, destination, time, and other relevant details that are available to iDialogs.
  4. The iDialogs Security and Privacy Officers are authorized to select and use auditing tools that are designed to detect network vulnerabilities and intrusions. Such tools are explicitly prohibited by others, including Customers and Partners, without the explicit authorization of the Security Officer. These tools may include, but are not limited to:
    1. Scanning tools and devices
    2. Password cracking utilities
    3. Network sniffers
    4. Passive and active intrusion detection systems
  5. The iDialogs Organization utilizes several tools and applications designed to assist in monitoring, threat detection, threat mitigation, and auditing to ensure compliance  and conform to CFR § 164.308(a)(5)(ii)(B) & (C). Any tools or software employed by the iDialogs Organization must be approved and documented by the iDialogs Security Officer.  These tools and software include:
    1. OSSEC: Utilized as a host-level intrusion detection system (HIDS).  The OSSEC HIDS encapsulates a wide-range of capabilities and Log-Level Analysis and reporting on trigger events directly to the Security Officer which include:
      1. Monitoring file permission anomalies
      2. Monitoring file creation/deletion/modification
      3. Shell access grant/denial reporting
      4. Host-based firewall denial reporting
      5. Unknown network node detection
      6. System daemon status changes
    2. ARPWatch: Utilized to monitor and detect changes to the network. This includes new/lost host detection which is reported to the system log and monitored by OSSEC.
    3. SNORT: Utilized as a  network-level  intrusion detection & prevention system.  While OSSEC monitors activity within its host machine, SNORT monitors network traffic and packet sniffing/logging.  SNORT trigger events are logged and analyzed by OSSEC.
    4. LMD & ClamAV: Linux Malware Detect and ClamAV are used in conjunction with one another in order to provide complete security against malware such as rootkits.  Signatures are updated daily and scanning can even prevent zero-day attacks.
    5. Linux Audit: Utilized to create an audit trail. All actions occurring on the target server are logged with date/time, user name, action, etc.
  6. iDialogs shall identify trigger events or criteria that raise awareness of questionable conditions of viewing of confidential information. The events may be applied to the entire iDialogs Platform or may be specific to a Customer, partner, business associate, Platform Add-on or application (See Listing of Potential Trigger Events below).
  7. Logs are reviewed weekly by the Security Officer.
  8. iDialogs treats its Dashboard as a Platform Add-on and, as such, it logs all activity associated with Dashboard Access.
  9. The process for review of audit logs, trails, and reports shall include:
    1. Description of the activity as well as rationale for performing the audit.
    2. Identification of which iDialogs workforce members will be responsible for review (workforce members shall not review audit logs that pertain to their own system activity).
    3. Frequency of the auditing process.
    4. Determination of significant events requiring further review and follow-up.
    5. Identification of appropriate reporting channels for audit results and required follow-up.
  10. Vulnerability testing software may be used to probe the network to identify what is running (e.g., operating system or product versions in place), whether publicly-known vulnerabilities have been corrected, and evaluate whether the system can withstand attacks aimed at circumventing security controls.
    1. Testing may be carried out internally or provided through an external third-party vendor. Whenever possible, a third party auditing vendor should not be providing the organization IT oversight services (e.g., vendors providing IT services should not be auditing their own services - separation of duties).
    2. Testing shall be done on a routine basis, currently monthly.
  11. Software patches and updates will be applied to all systems in a timely manner.  Security patches will be applied as soon as they are available.  If a known vulnerability is reported but no security patch is available, the iDialogs Security Officer will take steps to mitigate the risk.

8.3 Audit Requests

  1. A request may be made for an audit for a specific cause. The request may come from a variety of sources including, but not limited to, Privacy Officer, Security Officer, Customer, Partner, or an Application owner or application user.
  2. A request for an audit for specific cause must include time frame, frequency, and nature of the request. The request must be reviewed and approved by iDialogs Privacy or Security Officer.
  3. A request for an audit must be approved by iDialogs Privacy Officer and/or Security Officer before proceeding. Under no circumstances shall detailed audit information be shared with parties without proper permissions and access to see such data.
    1. Should the audit disclose that a workforce member has accessed ePHI inappropriately, the minimum necessary/least privileged information shall be shared with iDialogs Security Officer to determine appropriate sanction/corrective disciplinary action.
    2. Only de-identified information using the Safe Harbor method shall be shared with Customer or Partner regarding the results of the investigative audit process. This information will be communicated to the appropriate personnel by iDialogs Privacy Officer or designee. Prior to communicating with customers and partners regarding an audit, it is recommended that iDialogs consider seeking risk management and/or legal counsel.

8.4 Review and Reporting of Audit Findings

  1. Audit information that is routinely gathered must be reviewed in a timely manner, currently monthly, by the responsible workforce member(s). On a quarterly basis, logs are reviewed to assure the proper data is being captured and retained. The following process details how log reviews are done at iDialogs:
    1. The Security Officer initiates the log review by creating an Issue in the JIRA Compliance Review Activity (CRA) Project.
    2. The Security Officer, or a iDialogs Security Engineer assigned by the Security Officer, is assigned to review the logs.
    3. Relevant audit log findings are added to the Issue; these findings are investigated in a later step. 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. Relevant findings are reviewed at this stage. If the Issue is rejected, it goes back for further review and documentation. The communications protocol around specific findings are outlined below.
    5. If the Issue is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
  2. The reporting process shall allow for meaningful communication of the audit findings to those workforce members, Customers, or Partners requesting the audit.
    1. Significant findings shall be reported immediately in a written format. iDialogs' security incident response form may be utilized to report a single event.
    2. Routine findings shall be reported to the sponsoring leadership structure in a written report format.
  3. Reports of audit results shall be limited to internal use on a minimum necessary/need-to-know basis. Audit results shall not be disclosed externally without administrative and/or legal counsel approval.
  4. Security audits constitute an internal, confidential monitoring practice that may be included in iDialogs performance improvement activities and reporting. Care shall be taken to ensure that the results of the audits are disclosed to administrative level oversight structures only and that information which may further expose organizational risk is shared with extreme caution. Generic security audit information may be included in organizational reports (individually-identifiable e PHI shall not be included in the reports).
  5. Whenever indicated through evaluation and reporting, appropriate corrective actions must be undertaken. These actions shall be documented and shared with the responsible workforce members, Customers, and/or Partners.
  6. Log review activity is monitored on a quarterly basis using JIRA reporting to assess compliance with above policy.

8.5 Auditing Customer and Partner Activity

  1. Periodic monitoring of Customer and Partner activity shall be carried out to ensure that access and activity is appropriate for privileges granted and necessary to the arrangement between iDialogs and the 3rd party. iDialogs will make every effort to assure Customers and Partners do not gain access to data outside of their own Environments.
  2. If it is determined that the Customer or Partner has exceeded the scope of access privileges, iDialogs' leadership must remedy the problem immediately.
  3. If it is determined that a Customer or Partner has violated the terms of the HIPAA business associate agreement or any terms within the HIPAA regulations, iDialogs must take immediate action to remediate the situation. Continued violations may result in discontinuation of the business relationship.

8.6 Audit Log Security Controls and Backup

  1. Audit logs shall be protected from unauthorized access or modification, so the information they contain will be made available only if needed to evaluate a security incident or for routine audit activities as outlined in this policy.
  2. All audit logs are protected in transit and encrypted at rest to control access to the content of the logs.
  3. Whenever possible, audit trail information shall be stored on a separate system to minimize the impact auditing may have on the audited system and to prevent access to audit trails by those with system administrator privileges. This is done to apply the security principle of “separation of duties” to protect audit trails from hackers. Audit trails maintained on a separate system would not be available to hackers who may break into the network and obtain system administrator privileges. A separate system would allow iDialogs to detect hacking security incidents.
  4. Audit logs maintained within an application shall be backed-up as part of the application’s regular backup procedure.
  5. iDialogs shall audit internal back-up, storage and data recovery processes to ensure that the information is readily available in the manner required. Auditing of data back-up processes shall be carried out:
    1. On a periodic basis (recommend at least annually) for established practices and procedures.
    2. More often for newly developed practices and procedures (e.g., weekly, monthly, or until satisfactory assurance of reliability and integrity has been established).

8.7 Workforce Training, Education, Awareness and Responsibilities

  1. Workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and patient protected health information. iDialogs' commitment to auditing access and activity of the information applications, systems, and networks is communicated through new employee orientation, ongoing training opportunities and events, and applicable policies.
  2. Workforce members are made aware of responsibilities with regard to privacy and security of information as well as applicable sanctions/corrective disciplinary actions should the auditing process detect a workforce member’s failure to comply with organizational policies. See Policy # 8.2 “HIPAA Security Oversight”; Policy # 9.1 “HIPAA Privacy and Security Training; and Policy # 9.2 “Responding to Employee Noncompliance with Polices and Procedures Relating to the HIPAA Privacy and Security Rules."

8.8 External Audits of Information Access and Activity

  1. External Audits of Information Access and Activity Information system audit information and reports gathered from contracted external audit firms, business associates and vendors shall be evaluated and appropriate corrective action steps taken as indicated. Prior to contracting with an external audit firm, iDalogs shall:
    1. Outline the audit responsibility, authority, and accountability.
    2. Choose an audit firm that is independent of other organizational operations.
    3. Ensure technical competence of the audit firm staff.
    4. Require the audit firm’s adherence to applicable codes of professional ethics.
    5. Obtain a signed HIPAA-compliant business associate agreement.
    6. Assign organizational responsibility for supervision of the external audit firm.

8.9 Retention of Audit Data

  1. Audit logs shall be maintained based on organizational needs. There is no standard or law addressing the retention of audit log/trail information. Retention of this information shall be based on:
    1. Organizational history and experience.
    2. Available storage space.
  2. Reports summarizing audit activities shall be retained for a period of six years in order to conform to HIPAA Security Rule 45 CFR §164.105(c)(2) – Implementation Specification: Retention Period.
  3. Audit log data is retained locally on the audit log server for a one-month period. Beyond that, log data is encrypted and moved to warm storage (currently Rackspace Block Storage) using automated scripts, and is retained for a minimum of one year.

8.10 Potential Trigger Events

  1. High risk or problem prone incidents or events.
  2. Business associate, customer, or partner complaints.
  3. Known security vulnerabilities.
  4. Atypical patterns of activity.
  5. Failed authentication attempts.
  6. Remote access use and activity.
  7. Activity post termination.
  8. Random audits.

8.11 Documentation Requirements

  1. Audit logs and audit trail report information shall be maintained based on organizational needs. Retention of this information shall be based on:
    1. Organizational history and experience.
    2. Available storage space.
  2. Reports summarizing audit activities shall be retained for a period of six years. See HIPAA Security Rule 45 CFR §164.105(c)(2) – Implementation Specification: Retention Period.