#hit security

Recently Kroll Inc. has written several articles about the importance of understanding logs as a critical component of investigation security breaches. Acquiring and analyzing logs are critical with incident response and it is highly recommended that healthcare organizations address log management in a proactive manner. HIT Consultant spoke with Alan Brill, Senior Managing Director at Kroll Inc., to discuss the importance of log management & analysis for security in healthcare organizations. Highlights of part 1 of this interview include:

 Best practices for log analysis as a data security tool

Remote hosting/cloud

Using data logs to detect abnormal server activity

LISTEN NOW USING THE PLAYER BELOW OR CLICK HERE TO DOWNLOAD PODCAST

  HIT Consultant:  According to Verizon’s 2011 Data Breach Investigations Report, less than one percent of the breaches analyzed were discovered through log analysis, while 69 percent of those breaches were detectable via log evidence. Why are healthcare organizations not maintaining their logs?

Alan Brill:  That’s a really interesting statistic when you think about it. Sixty-nine percent of the breaches could have been detected from the information in the logs, but only 1% was actually discovered from looking at the logs. What that indicates is that in 68% of the braches, if there had been logs and those logs had been reviewed, the breach would have been caught sooner and understood better. So the question is, how do you get a number like that? Most organizations have been thinking about logging in any organized sense for a long time, maybe even years. Also, things have changed. Years ago, people would say they would keep logs for a couple days or so, because they take up so much room, and space is so expensive. That’s what you would hear, but today space isn’t that expensive. Large amounts of storage don’t end up costing necessarily a great deal and it is time to re-think what we log, how we log it, how we maintain those logs, and how we use those logs. I think the real answer to your question is because healthcare organizations haven’t really focused on the value equation that is associated with those logs. If you think of them as just as something for IT to use in case there is a problem, you start to ask that question, how much is it worth to us? But, once you recognize that those logs can be of enormous value in a breach, perhaps we will go through one or two examples to show what exactly that value could be. Once you say that, it’s a whole different ball game. Now those logs may have strategic importance to the business in determining where a breach occurred, if it occurred, how serious and how it has to be reported? So the message that I get from that part of the report is an indication of the enormous value that good logging can have in dealing potential and actual breaches.

HIT Consultant:  What are some best practices for log analysis as a data security tool?

Alan Brill:  The first thing is to have the logs turned on. I can’t tell you how many times when our teams come in when something terrible has happened and one of the first things we say is, let’s grab the logs, and let’s preserve them. Then we talk to the IT people and they say, well unfortunately we have turned off most of the logs. Eventually you ask them why and they say things like too much space and really didn’t see a value to them. So, I think the first practice is to have logs turned on where it’s practical and to maintain them for a long period that they are likely to be useful if you discover a security incident or a potential breach. You then have to have the ability to take those logs and do something with them, analyze them, bring them together from disparate parts of the organization to get a picture of what’s really on as a whole. So, the process that we look at is log consolidation, log preservation and log analysis. For each of these, there are tools, both open source and commercial that you can use to make this process easier for your technology staff. But, you have to start off with the best process for log analysis as having logs you can analyze and have simple tools to help you go through the logs so that you can turn a massive amount of raw data into what we refer to as “actionable intelligence.” It tells you something in a way that helps you do something about it. For example, if you are suddenly getting something in a log a lot of inquiries or hits or accesses from a part of the world that you just don’t do business in, that may be something on the business end worth taking a look at.  You may find data going out that you did not expect; that is certainly worth knowing. So, there is a whole range of things you do with log analysis from looking at what’s coming in and what’s coming out of the organization to looking for unusual patterns. The best practice really requires for you to figure out for your particular institution how can logs become useful? In some cases, where there are a lot of resources, you may be able to do a lot of pro-active analysis. In smaller institutions, you may be more limited, you may be primarily maintaining those logs in case there is an incident…in case there is a need for them. So there is no magic single solution, but the first thing to do is make sure you are getting your logs, keeping them for a long enough period and know what you are and are not logging.

HIT Consultant:  You mentioned simple tools, what simple are you referring to?

Alan Brill:  There are a number of tools generally because of the range of technologies that people use from different operating systems to large versus small institutions. There is no real way to give a list of real specific tools that you can recommend. There are too many and a tool that may be appropriate for one organization may be wildly inappropriate for another.

HIT Consultant:  HIPPA Security Rules require covered entities to regularly review information system activity through records such as audit logs, access reports and security incident tracking reports. What about healthcare organizations who have their systems remote hosting or in the cloud?

Alan Brill:  That is the key word of today, is it in the cloud? We store things in the cloud; we process things in the cloud. The simplest answer to that question is that you cannot let it make a difference. The law does not give you a free pass, a get out of jail free card by saying we store our data in the cloud or we use remote hosting. Organizations have a responsibility under HIPPA/HITECH and that responsibility exists regardless of the technology that you use. What that means is as healthcare institutions, start making increasing use of remote hosting, storage as a service and infrastructure as a service. All of these cloud based constructs, you have to be sure that you are implementing those in a way that is going to be compatible with the HIPPA security rule. For example, if you discover that there is no way to audit who had access to sensitive information. That is not going to fly. You cannot simply go in after something bad happens and say at least we could have could have been fully compliant, but the cloud provider said they do not do things in a way that is compliant. So that is the end of the story. As you can imagine, when you go the government with that each story, it is not going to be the end of the matter. So remember again the simple rule that the technology you employ does not matter. You still have to be, not only comply with the security rules, but to be able to demonstrate that you are compliant with those security rules. Partially, this is involved initially before you even sign a contract to use any form of remote hosting, remote computing or “the cloud.” You need to ask the questions, how are we going to be compliant? Are you compliant? Are you provider compliance tools for other healthcare providers? What are those tools? Can I talk to them? Those are the kinds of questions you need to ask? Fail to ask them, because the cloud has somehow mesmerized you into saying, wow it’s cost effective, it’s easy. It takes us out of doing things we are not really good at doing. You are on a slippery slope and you don’t want to go there.

HIT Consultant:  According to your recent release, Kroll states that data logs are your guide to detecting abnormal server activity; can you tell me more about how this relates to healthcare organizations?

Alan Brill:  One of the questions that you get asked almost immediately in any case where people think there is a breach is essentially, what happened? What records were stolen, what records were at risk? Do we know what happened in this case? In most situations, you deal with the answer is not going to on some end user’s computer it is going to be on the server. Most often, it will be a file server, some form of processing server. For example, we had a client who came to us and found out they had been the target of a successful attack. In this particular case, the target was not healthcare information, it was credit card numbers. When they looked at their file, they realized that they had about 380,000 credit cards that were at risk and as far as their IT people were telling them they did not know that one had been stolen or none had been stolen or all had been stolen. As you can imagine, there is a big difference in reporting a few cards and reporting several hundred thousand cards in terms of the level of effort and in terms of the cost. What we did in that case, we went in and were able to get logs from the server. Those server logs told us a few things. One, we could see data that was actually leaving the system.  When we looked at the data, we thought of it being a very unusual pattern that is as you looked at the stolen data, all the credit card numbers started with the digit 3 and we could not figure out why. Why would a successful attack only target American Express product, so what we did was to be able to determine the malware in the system and we reversed engineered it. The thing we discovered was the malware, whether on purpose or by error had inside of it a test that essentially said, if the first digit of the credit card number is a 3, steal it.  If it is a 4, 5, or anything else, ignore it. The first thing we discovered that it wasn’t 380,000 cards at risk. It was only American Express cards and that was huge reductions that reduce it to only about 75,000 records. The other thing we discovered by looking at the logs that there appeared to be a very limited period of when data was flowing out. When we looked inside the malware (virus), we discovered again that purposely or because of a programming error, it had a deadline. It only operated up until a certain date and then it stopped working. So when you added a date to the other information, we went from a need to notify over 300,000 people to about 17,000 people; however, that is still a lot of people. If you think about it, that is a lot less costly, less aggravating and will probably have a lot less of an impact, reputation wise, having 17,000 whose data was compromised than it would be to have almost 400,000. So, there is almost always useful information in the server logs. That’s why our field investigative teams always look to secure those as quickly as they get in there. In fact, while they are on their way, we generally talk our clients through the process if they can preserve the server logs so that they are not getting overwritten, so that they are not getting accidently erased during initial triage internally do find out what went wrong.

Part 2 of this interview/podcast coming soon…

About Alan Brill: Alan Bill is the Senior Managing Director of Secure Information Services at Kroll. The author or co-author of seven books and dozens of articles, he is frequently quoted in the media in his field of expertise. He has conducted analyses of security for a wide range of global companies and led incident response teams handling a wide range of incidents involving personal, health, proprietary and classified data. He has served as an expert witness in federal and state courts and as a special master for the federal courts. He has provided expert testimony before Congress, having been invited to do so by the majority and minority leaders of the committee.