6 min read
HIPAA Logging HOWTO, Part 2
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) outlines relevant security and privacy standards for health information – both electronic and physical. The main mission of the law is “to improve portability and continuity of health insurance coverage in the group and individual markets, to combat waste, fraud, and abuse in health insurance and health care delivery” (HIPAA Act of 1996 http://www.hhs.gov/ocr/privacy/). A recent enhancement to HIPAA is called Health Information Technology for Economic and Clinical Health Act or HITECH Act. The act seeks to “promote the adoption and meaningful use of health information technology” and “ addresses the privacy and security concerns associated with the electronic transmission of health information.“(HITECH Act of 2009 )
As we mentioned before, HIPAA itself does not descend to the level of security controls and technologies to implement. This requires the organizations affected by HIPAA – also known as “covered entities” –to try to follow the spirit of the regulation as opposed to its letter. What is also interesting to note is that insurance companies and many hospitals that accept payment cards are subject to both HIPAA and PCI DSS (covered in our previous newsletters). Understandably, the scope of their applicability across the organization might be different since payment processing systems should not store patient health information and vice versa. Still, considering the same technical and administrative controls for both regulations is prudent and will save money in both the short term and long term.
The previous newsletter focused on general HIPAA logging and log review processes and platform logging. This newsletter installment covers application logging issues specific to medical applications.
While platform level logging is useful for protecting sensitive health information, and it is a fact that a majority of health information is stored in databases and processed by healthcare specific applications and. Such applications are either procured from specialty vendors or developed internally – war via outsourced developers.
HIPAA of audit controls, mentioned in Section 164.312(b), apply to application logging as much or more than to platform logging. This means that custom applications need to be engineered to have adequate logging. Existing application logging needs to be assessed having adequate logging – it should be noted that many legacy applications will often not record sufficient details for events and might even skip logging events altogether. Thus, before embarking on this project, it makes sense to determine which applications within your organization contain Protected Health Information (PHI) and what their existing levels and methods of logging are.
Let’s define some of the guidance for what to log to satisfy the spirit and letter of HIPAA Security Requirement as well as NIST 800-66 HIPAA clarifications.
Before we can define good HIPAA logging, let’s consider typical security use for log data.
From high-level, best audit logs tell you exactly what happened – when, where and how- as well as who was involved. Such logs are suitable for manual, semi-automated and automated analysis. Ideally, the can be analyzed without having the application that produced them at hand – and definitely without having the application developer on call. In case of healthcare applications, such developer might not be an available at all and the security team will have to proceed on their own. From the log management point of view, the logs can be centralized for analysis and retention. Finally, they should not slow the system down and can be proven reliable, if used as forensic evidence.
Two primary things need to be defined.
- First, there are types of activities or events that always needs to be recorded. For example, authentication decisions, health information access and system changes should always appear in logs.
- Second, for each type of a recorded event there a particulate details that a mandatory for its interpretation, whether by a human or by an automated system. For example, every log should have a reliable time stamp and every log related to user activity should contain the username of that user.
It should also be noted that certain details should never be logged. The example is obvious: application or system passwords should never appear in logs (this, sadly, still happens for web applications sometimes). Just as obviously, the health information itself should be kept out of logs.
What events to log?
What is the overall theme for selecting which events to log?
Clearly, we need to know who, when and why accesses any of health information. We also need to know who adds, changes or deletes it. But this is not all – we also need to note who tries but fails to read, change or delete information. If we are unable to record access to each piece of data, we need to carefully record all access to the application itself.
Next, we need to know who performs other actions on systems that process health information as such activities might affect future access to healthcare data. For example, we need to record if somebody turns logging off or adds a new component to the system which might enable unfettered access to data. In addition, we need to record other critical events a caring on health information systems, as such events might present circumstantial evidence for unauthorized access.
The following list presents a structured view of the above criteria:
- Authentication, Authorization, Access
- Authentication/authorization decisions, successful and failed (see “status” below) – and especially privileged authentication
- Recording user logoffs is also important for knowing when user no longer had access to the application
- Switching from one user account to another
- System access, data access, application component access
- Network access to the application, including remote access from one application component to another in a distribute environment
- Changes
- System/application changes (especially privilege changes)
- Data change (creation and destruction are changes too)
- Application and component installation and updates as well as removals
- Sensitive data changes, additions and deletions
- Availability Issues
- Startups and shutdowns of systems, applications and application modules/components
- Faults and errors, especially those errors that affect the availability of the application
- Backups successes and failures (affect availability)
- “Badness” / Threats
- Invalid inputs other likely application abuses
- Malicious software detection events
- Attempts – successful and failed- to disrupt or disable security controls or logging
- Logging termination events and possibly attempts to modify or delete the logs
- Other security issues that are known to affect the application
While creating a comprehensive ”what to log” list for every healthcare application in existence is probably impossible, the above list should give you a useful starting point for your relevant applications. It can be converted into your application logging policy without much extra work. Please refer to previous newsletter for setting up log monitoring and review process.
What details to log?
Next, what data should you log for each event, and at what level of detail should you log it? The overall theme we use here is the following:
Who was involved?
What happened?
Where did it happen?
When did it happen?
Why did it happen?
How did it happen?
The list below gives you a starting point based on that theme:
Timestamp + time zone : this helps to answer “when” question, time zone is essential for distributed applications
System, application or component: this helps to answer “where” question and needs to provide relevant application context as well
Source: for messages related to network connectivity or distributed application operation, logs also need to answer “where from” question by providing a network source.
Username: this helps to answer “who” question – for those events that are relevant to user or administrator activities
Action: this helps to answer “what” question by providing the nature of the event that is recorded in the log
Object: this also helps to answer “what” question by helping to know which system component or other object (such as user account) has been affected
Status: this also helps to answer “what” question by explaining whether the action aimed at the object succeeded or failed (other types of status are also possible, such as “deferred”)
Priority: last but not least, every logged event should have an indication of how important it is. While creating a uniform scale for renting events by importance is impossible since different organizations will have different priorities (for example, events affecting availability vs. confidentiality of information might be read differently)
Thus, a useful application audit log message might look like this:
2010/12/31 10:00:01AM GMT+7 priority=3, system=mainserver, module=authentication, source=127.0.0.1, user=anton, action=login, object=PHI_database, status=failed, reason=“password incorrect”
By the way, notice that another field is added to the above example log message in order to explain the reason for failure. Also notice that the above examples is not in XML – as we mention above, human readability is a useful property to have in logs and computers can deal with name=value pairs just as well as with XML. XML Health Level Seven (HL7) based messages can be easily converted to text, for those application that can log in HL7.
We also mentioned above that being able to easily centralize logs is essential for distributed log analysis either across multiple systems or across multiple application components of a distributed application. While syslog has been the king of log centralization due to its easy UDP delivery, modern cross-platform application frameworks like a call for publish/subscribe model for log delivery, similar to the ones used in modern Windows versions. In this case security monitoring tool can request a subscription for a particular type of a logged event – and receive all relevant logs in near real-time, if needed.
In addition to that very basic conclusion – you must log access to sensitive healthcare data– we have to remind our readers that the importance of logging will only grow – along with growing application complexity. In particular, the need to analyze application behavior and movement of sensitive information across distributed and cloud-based application calls for us to finally get application logging under control.
Software architects and implementers need to “get” logging – there is NO other way since infrastructure logging from network devices and operating systems won’t do it for detecting and investigating application level threats to ePHI. Security team – ultimately responsible for log review – will need to guide developers towards useful and effective logging that can be used for both monitoring and investigative activities.
Certainly, logging standards such as MITRE CEE (cee.mitre.org) will help – but it might take a few years before they developed and their adoption increases. Pending a global standard, an organization should quickly build and then use its own application logging standard for applications. HIPAA compliance presents a great motivation to creating and adopting such logging standards.
Industry News
Pirate Bay hack exposes user booty
Security weaknesses in the hugely popular file-sharing website thepiratebay.org have exposed the user names, e-mail and Internet addresses of more than 4 million Pirate Bay users… An Argentinian hacker named Ch Russo said he and two of his associates discovered multiple SQL injection vulnerabilities that let them into the user database for the site.
Zeus is back with terrorism-themed spam run
Trojan-laden emails claiming to offer official terrorism information have been hitting inboxes… The emails are spoofed to look like they originate from the U.S. Department of Homeland Security, Pentagon or Transportation Security Administration. Users are encouraged to click on two links, supposedly leading to reports, but which are actually ZIP files containing the insidious Zeus, or Zbot, trojan.
Related Resource: Webinar – Learn how implementing change control in your enterprise can help you handle critical security challenges including BOTnet and zero-day attacks.
Database admin gets 12 months for hacking employer
A former database administrator for Houston’s GEXA Energy was sentenced to 12 months in prison and fined $100,000 for hacking into his former employer’s network. He remotely accessed the GEXA Energy network without authorization, impaired the availability of data and copied a database file containing personal information. GEXA Energy estimates that Kim’s actions resulted in a loss of at least $100,000.
Did you know? Security violations by insiders are often the hardest to discover, but cause the greatest damage and cost the most to repair. EventTracker helps by monitoring all user and admin activity, automatically detecting policy violations and out-of ordinary or suspicious behavior
