13.4 IMPLEMENTING AUDIT MECHANISMS ( 164.312(B))


13.4 IMPLEMENTING AUDIT MECHANISMS ( § 164.312(B) )

(b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

HIPAA maintains that EPHI is verified for integrity and that controls are in place to review and validate those requirements. The following are suggested directives taken from the Federal Information Systems Controls and Audit Manual (FISCAM):

  1. User account activity audits are conducted using automated audit controls.

  2. Computers systems processing sensitive information are secured from unauthorized access. All security features are available & activated. Audit facilities are utilized to assure that everyone who accesses a computer system containing sensitive information is accountable.

  3. All activity involving access to & modifications of sensitive or critical files is logged.

  4. Access to audit logs is restricted.

  5. The audit trail includes sufficient information to establish what events occurred & who or what caused them.

  6. Audit logs are reviewed periodically & retained for the same period as the original claim.

  7. All hardware fault control routines are logged to indicate all detected errors & determine if recovery from the malfunction is possible.

Network infrastructure devices such as routers, switches, remote access servers typically have an inherent system logging (syslog) service that can provide many levels of event logging. A suggested minimum setting of alerting should be enabled that will report exception events separate from normal operating actions. For example, one could monitor for unauthorized configuration changes.

Network security devices such as firewalls, Proxies, Sniffers, Content filters, Intrusion Prevention/Detection systems should be implemented in environments involving Internet and Extranet access. These solutions monitor network activity as it enters and exits the Covered Entity. All of these systems have varying degrees controls and logging detail. Access rules should be defined as they pertain to a risk analysis, and logging of these controls should compliment the determined risk management. For example, logging is monitored to determine if unauthorized access has occurred that conflicts with Internet Access policies defined within the Administrative Safeguards. Another example could monitor for ingress access to sensitive systems containing EPHI.

Host systems such as Mainframes, Open system servers such as Novell, Microsoft and Unix should have logging enabled to monitor for intruder authentications, failed login attempts, logins and logouts, access to sensitive EPHI, service restarts, system failures, user account creations, etc. For example, one could enable read/write auditing for patient files and cross check this with a list of authorized accounts. Another example would monitor for system administration accounts that become disabled due to exceeded intruder lockout thresholds. System hardware events, such as disk and memory failures may also be logged and monitored.

Applications such at Anti-virus, Electronic mail, Web traffic, and Databases can be logged and monitored for events, egress access, and access to sensitive data. For example, it is important to monitor for anti-virus systems to ensure the most current virus signature data is updating correctly and virus outbreaks are mitigated. Databases could be monitored for unauthorized access to sensitive tables as well as modifications to table configurations.

As prescribed within the FISCAM directives, system log analysis should be performed on a routine basis and monitored for anomalies and significant events. These events should be acted upon, and those remediation measures taken should also be logged for review and mitigation purposes.

Log retention is based upon best security practices, and typically is retained anywhere from 1 month to 1 year. HIPAA requires that the original log format must remain intact or can be reproduced back to the original content if archived in a compressed format. Logging mechanisms must be restricted from unauthorized access to ensure integrity and validity. For example, this may require that only specific computers can access the log data and require authorization and authentication for the review process (see ( § 164.312(a)(1)).

Typically, systems have localized log services and log data. This hinders the requirement for log monitoring and review due to the amount of time and effort it takes to interrogate the log data. In large environments, it may be necessary to deploy a consolidation system for log collection and retention. This facilitates the process for log review and analysis and enhances the opportunity for event correlation. For example, in an environment containing numerous network devices, servers and applications, a centralized log management system collects logs from the independent systems and melds the data into a single storage and management solution. Event correlation can then be executed, which allows the monitoring of events as it transgresses through the environment and provisions for forensics in the event of an incident.

One caveat of log consolidation is that log integrity must be taken into consideration. If logs originate from an internet facing device, encryption may be warranted to maintain the integrity and minimize exposure of the data. Furthermore, syslog is based on UDP (connectionless, less reliable protocol), and may need to be replaced by its successor, syslog-ng that utilizes TCP (connection, more reliable based protocol) thus minimizing log data loss during transmission.

Policies and procedures should be defined that describes how systems are monitored and audited to ensure uniformity and consistency throughout the review process. Additionally, requests for account creations, access modifications and deletions could be managed by a mechanism designed around administrative management approval to ensure that security profiles changes are authorized. For example, if log data shows that a system administrator account was created, it could be verified against the originating administrative request.




HIPAA Security Implementation, Version 1.0
HIPAA Security Implementation, Version 1.0
ISBN: 974372722
EAN: N/A
Year: 2003
Pages: 181

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net