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
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.
|
|