purdue university. university policies.
advancement. facilities and lands. finances. governance. human resources. spacer.
spacer. information technology. records. students. teaching, research, outreach. spacer.
university policies home. spacer. site map. about policies. feedback.  
Information Technology
HIPAA Covered System and Application Logging

Table of Contents

Reason for Policy

Statement of Policy

Who Should Know This Policy

Related Documents

Contacts

Definitions


Reason for this Policy

HIPAA covered components at Purdue University are required to be in compliance with the Health Insurance Portability and Accountability Act (HIPAA) Security Rule.

This policy will ensure that systems processing and storing electronic Protected Health Information (PHI) are identified, monitored, and reviewed for compliance with existing University policy, procedures, and federal HIPAA regulations related to system activity controls. It will also discourage, prevent, and detect security violations.


Statement of Policy

Scope:

This policy covers all computer systems in the HIPAA covered components at Purdue that create, access, transmit, or receive electronic PHI used for treatment, payment, or health care operations or any form of electronic PHI where the host system is configured to allow access by multiple people.

Examples include:

  • a departmental server with file shares containing electronic PHI,
  • a clinical care system which contains primary source electronic PHI, and
  • other systems designated as covered by the Purdue HIPAA privacy officer.

Check with your HIPAA liaison or the HIPAA privacy officer if you are not sure your system is covered by this policy.

Policy Statement:

This policy identifies requirements for reviewing activities on computer systems containing electronic PHI at Purdue University.

To the maximum extent possible, logs from systems and applications containing PHI must capture information and events as described in the following table:

Risks or Control Objectives Requirement

General controls

  • Record who did what to which object, when, and on which system.

  • Record what events each system is capable of logging.

General events to capture

  • Machine startup and shutdown; startup and shutdown of audit function.

  • Successful/unsuccessful login and logout of users; denial of service events.

  • Add, modify, and delete actions on all data/files/objects; plus read/view actions on data classified as restricted.

  • Use of all privileged accounts and utilities.

  • Changes to user accounts or privileges (creation, modification, deletion).

  • Automatic logout of a user after exceeding a locally defined time of inactivity or excessive login attempts.

  • Switching to another user's access or privileges after logging in.

  • Software or hardware modification.

  • All access to security files, attributes, or parameters; any action to circumvent security controls including access to anti-virus software.

Operation events to capture

  • Login attempts with failed identification or authentication, also known as failed login attempts.

  • Changes of the time or date of the system clock.

  • Emergency mode operation.

  • Detection of a virus.

  • Detectable hardware and software errors; log failure and restart events.

  • Changes to log files (creation, deletion, and configuration).

Communication events to capture

  • Network link failures.

  • Device connection failure due to device identification or authentication failure (also known as a failed connection attempt).

  • Network and device connections dropped.

  • Data integrity verification failure for information transmitted over a network.

  • Message authentication failure for information transmitted over a network.

  • Overrides of network abnormality alarms and alerts.

  • IP addresses of successful and unsuccessful connections.

  • Changes to network security configuration (e.g. firewalls).

Content of audit trails

  • Date, time, type, and any applicable error condition of event.

  • The ID of the user who caused the event.

  • The application that created the audit event.

  • The application(s) responsible for executing the event.

  • The component or workstation that initiated the event, and where the event happened.

  • Description of the event, which may include before and after images.

Monitoring

  • Follow-up on suspicious events such as intrusion attempts, authorized accesses at unusual times, and unusual changes to infrastructure devices.

  • Identify, investigate, report, and respond to inappropriate activity.

  • Ensure that audit requirements and activities do not unduly disrupt critical business processes.

  • Identify the individuals performing event analyses. Each shall be independent from those setting audit trail rules. Ensure they are available and that they record who, what, when, where, and why sensitive information is released. Rules-of-evidence integrity must be maintained.

  • Document all event capturing and analysis procedures, requirements, and responsibilities, including when to involve inforensics specialists.

  • Develop a process to ensure that users comply with access control procedures, including strong password creation and protections.

  • Audit all user activity where risk levels warrant.

  • Employ event analysis support tools and/or e-intelligent methods of correlating log data to detect suspicious activity and reduce volume.

Maintenance and storage of audit trails

  • Audit trails must be managed only by authorized staff.

  • Audit trail retention will vary depending upon legal requirements and business need. PHI and audit trails must be archived for six years. Other federal laws and regulations may stipulate other retention periods; always use the most stringent guideline when the data is covered by more than one policy, law, or regulation.

  • Audit trail records management retention and disposal rules must be documented.

Activity Review

The activity review process shall include an audit of system activity logs and reports at a level commensurate with a particular system's profiled data criticality category. This process may include a review of the following types of system activity information:
    • Review of Security Incident Response reports
    • System user privileges system grants and changes logs
    • User-level system access logs, if available
    • User-level system activity logs, if available
    • User-level transaction log reports, if available
    • Exception reports
    • The required level of system activity logging and reporting capabilities, and the actual scope of the activity review for each risk profile should differ based upon a system's assigned data criticality level.

IT Security and Privacy and/or Internal Audit will carry out a full review or spot checks of user-level access, activity, and transaction and exception logs.

Who Should Know This Policy

  • President
  • Provost
  • Executive Vice President and Treasurer
  • Chancellors
  • Vice Presidents
  • Deans
  • Directors/Department Heads/Chairs
  • Principal Investigators
  • Faculty
  • Business Office Staff
  • Administrative and Professional Staff
  • Clerical and Service Staff
  • All Employees
  • Undergraduate Students
  • Graduate Students

Related Documents

Information about HIPAA compliance at Purdue
http://www.purdue.edu/push/HIPAA/

HIPAA Security Standard
http://www.cms.hhs.gov/hipaa/hipaa2/regulations/security/nprm/secnprm.pdf


Contacts

Subject E-mail
For questions about this policy itap-securityhelp@purdue.edu

Definitions

Word Definition

Protected Healthcare Information

Health information in any form that can be connected to a patient. Health information includes the individual's past, present, or future physical or mental health or condition, the provision of health care to the individual, or the past, present, or future payment for the provision of health care to the individual.


 

 

purdue homepage purdue search purdue maps purdue directories