Topics


Blogs


Forums


Samples


Media


Labs


Resources

 




DevCentral > Weblogs > Lori MacVittie - Two Different Socks
 Log Files Do Not Improve Security
posted on Wednesday, September 09, 2009 3:24 AM

Logs are for auditing, accountability, and tracking down offenders – not for providing real-time security

A new law signed into effect in February 2009 requires that health care providers and organizations shortstory subject to HIPAA notify affected customers in the event of a breach affecting more than 500 records. There was very little discussion of this new requirement in the blogosphere which was surprising given this statement hidden amongst one of the few articles on the subject.

Dominique Levin, executive vice president of marketing and strategy for log management vendor LogLogic, told SCMagazineUS.com on Thursday that there are security and privacy concerns with the move to digital health care records.

“Hospitals are now targeted by insiders and professional criminals trying to access health information for financial gain,” Levin said.

But, ultimately, computerized health care records could reduce costs, result in easy backups and data recovery, and actually improve security, Levin said.

“Electronic health care records can be more secure than paper records,” Levin said.

For example, companies can implement technologies that keep a record of everyone that has accessed the records -- something they can't do with paper records, Levin said.

The example of “better security” here is the implementation of a record, i.e. audit/log file, of everyone that accesses the records. 


RECORDING A BREACH DOES NOT PREVENT IT
Audit files do not improve security. Neither do log files. Both are simply tracking mechanisms that are little more than CYA mechanisms for organizations that help in the event security is breached. They are part of the forensic trail of evidence that can be used to assist in determining who may have had access and ultimately whether everyone who did access the resource was authorized to do so. Just take a look at the number of “hidden camera” footage videos on the Internet and you’ll quickly discover it’s not really a deterrent, it just forces criminals to take greater pains at disguising themselves and hiding their tracks. Take a good look at any generalized rootkit and you’ll find tools included for mucking with the log file – either to remove evidence or obfuscate it in such a way as to make it useless. Taking care of log files is merely one more item to be covered on the lengthy “to do after a successful breach list” of miscreants.

This is a recording of activity, it is not preventative. It does not improve security at all and it does absolutely nothing to assuage the concerns of those who may be able to see that making anything electronic – and available over the Internet – immediately degrades the security of those records because there are suddenly myriad additional attack vectors that must be identified and secured.

Paper records – health care records in this case – are accessed by medical folks. If you’ve ever tried to get a copy of your own personal records you know it requires signatures, notes from your parents, a completely filled out form specifying why you want the thing in the first place, and who can access it. HIPAA regulations require that only those so designated be allowed to see your records – at least those outside the medical organization – and even restrict to whom information can be given over the phone or e-mail. It is unlikely that electronic versions of these same records would involve the running of the gauntlet of forms and signatures required to access paper versions. They’ll be electronic - consumers and advocates hope available via the Internet - and absolutely open to attack.

That’s less secure, not more secure.

Now I’ll be more forgiving for a moment and note that Levin is quoted as saying electronic health care records can be more secure, not they will be.

But that’s a fine line to walk and the reality is that adding log or audit files does not improve security. Log and audit files are created after the event. The fact that Johnny asked for access is noted and that he was granted access is noted. There’s no participation, no collaboration, no prevention involved in logging an event. It is the recording for posterity (or the police) of an event. Period. It neither degrades nor improves security, it merely is what it is: another record. It is likely true that electronic records can provide better and more complete logs of who accessed records and when, but it doesn’t do anything to control that access in the first place.

Is it important? Yes. Should you have such records? Yes, you should. Are they required by some regulations? Absolutely.

Do they improve security? No.


SO HOW WOULD YOU IMPROVE SECURITY?

There are plenty of options for improving security of any kind of records that are stored and accessed digitally:

  1. Data leak prevention (DLP) The security of “last resort” that prevents the breach from succeeding. A security breach has happened, technically, but the results are kept from being delivered [PDF] and thus the sanctity of the records.
  2. Context-Aware Authentication A username and password is good, but when it’s coming from a Starbucks in New Foundland and the user is sitting in the office in Seattle, well, c’mon – there’s something fishy about that situation, isn’t there? Context-aware authentication systems and specifically those employing endpoint inspection capable of enforcing specific conditions such as location or peculiar identifying applications/machine properties before allowing access go a long way toward improving security.
  3. Web-application Firewall If access is provided via a web application, this should be a default additional solution. Preventing some of the ways in which people unlawfully gain access (XSS, SQLi) reduces the chances of a successful breach in the first place.
  4. Full stack security Security of the entire OSI stack – from layer 1 to layer 7 – is important in preventing existing and new vulnerabilities in platforms and protocols from being exploited at the expense of the security of data.

That’s in addition to – not in place of – a secure development life cycle (SDLC), well-defined organizational-wide security policy, and auditing of that policy and its technical implementation to ensure that every possible precaution against a breach is taken.

Logging is an integral part of organizational security policies and best practices and well it should be. But don’t make the mistake of thinking that logging access to records is the same as securing them.

Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share

 

Related blogs & articles:



 
      

Feedback


9/9/2009 6:48 AM
Gravatar You make some good points about real-time security and how recording log files doesn't directly resolve security issues. Your blanket statement of how "Log Files Do Not Improve Security" though is extremely short-sighted.

If all you have is real-time security and you do not archive all electronic activity (as manifest in log files) in the electronic network that houses your data then:

* how can you be assured there really are
no security breaches? you may not have
thought of everything when setting up
your firewalls and other security
mechanisms ... a log-based archive
of electronic activity lets you
investigate history as you uncover
potential vulnerabilities you didn't
know of before and see evidence of
transgressions involving your
shortcomings in the past

* if all you have is real-time security
and suddenly you find your electronic
data out free in the world ... how do
you even begin to find how the
perpetrators got into your network?
do you wait for them to do it again?
that's brilliant. it's very likely
the perpetrators didn't even attack
you from the outside ... they're
probably insiders. your beautiful
lily of a real-time security perimeter
don't even help you there ... the trace
is in the logs.

* with log data archiving you CAN go
find those unscrupulous insiders,
find the machine from which they
grabbed data they shouldn't have,
find their IP address and their
identity. log archival keeps those
insiders with easy access to info
a bit more honest (the health
care worker will be less interested
in looking at celebrity's treatment
record if they know they can be
discovered) and lets you find who
they are when they've stolen SSNs
and credit card numbers

A real-time-security-only approach is death. The log archive protects against unforeseen breach mechanisms, protects from insiders, and will give you critical feedback to better inform real-time security in your evolving electronic network.

When it comes to buying your log archival system forget LogLogic. The NSA/IRS/Treasury-Dept/Navy all use SenSage (http://www.sensage.com), as do tons of banks, telcos, health providers, insurance companies, and others.
Urca Braz

9/9/2009 9:04 AM
Gravatar Though I believe that I might disagree with you, I'm not sure where.
So, I would really appreciate some clarification.

How do you define a log?
How do you contrast "logging" to "monitoring"?
Would it be fair to define logging as monitoring and recording over time?

How exactly do you propose to detect and respond to anomalous behavior without first observing, recording and analyzing all behavior?

Log and audit files may be created "after the event", but if you're logging properly, the relevant event will not be the actual breach, but the identification of malicious behavior immediately preceding a breach.

Identifying any pattern of behavior at all seems, at least to me, quite difficult without recording the behavior in an organized, methodical fashion. Identifying telltale malicious behavior without a baseline of benign behavior to compare it against would pose an even larger challenge.

Interestingly enough, one of the most compelling and useful suggestions you offer as an alternative seems to implicitly require logging. Your second suggestion, context aware authentication, is creative (though I'm not sure if it's original, as i've focused more on multi factor auth than context analysis). However, performing any sort of context analysis without respect for previously observed contexts appears, at least on the surface naive. I would hope that your commercial solution incorporates not only the present context but the history of all successful and unsuccessful authentication contexts.

I'm sorry if this sounds like I'm jumping down your throat, but categorically dismissing logs as an after the fact "CYA mechanism" is a dangerous message to send to your readers. I wholeheartedly believe that logs are the foundation upon which your favorite "real-time" and "proactive" solutions are built upon, and would be interested in whether or not your disagree.

PS, i came upon this post from Paul Graham's "hacker news".
Your piece has provoked a discussion that you may or may not wish to participate in. We would love to continue the conversation, if you'd like to join in.
James

9/9/2009 9:32 AM
Gravatar @James

My disagreement with the quote is that it implies all you have to do is log and security will be better. As you point out, many many many other solutions (reactive and proactive) are based on the analysis of log files.

Others are based on real-time traffic analysis. If logs did not exist, then it is likely more solutions would be based on real-time traffic analysis than are today. Whether that is a good thing or not is up for debate and not really all that relevant except to illustrate that third-party tools - the ones that provide the real value - make use of logs, but logs in and of themselves do not improve (or degrade, for that matter) security. They are merely data that, if not leveraged, will simply take up space. Logs are an enabling technology - required for many solutions - but are security neutral.

You don't sound like you're jumping down my throat at all, you sound like you're trying to have a conversation - which is one of the purposes of blogs in the first place - and I'm happy to have that conversation.

I'll jump on over to the discussion on hacker news - am happy to continue the conversation.

Lori MacVittie

9/9/2009 11:41 AM
Gravatar I think some of the arguments here are missing the point. This article isn't against logfiles. It's against complacency. For most people, security isn't their business. They want to be safe with the minimum effort. They want their institutions to be safe with minimum cost. They don't understand, nor want to understand the issues involved. If a law is passed to "solve" the security problem, people will assume it does. If the law only mandates keeping logs, then that is all that will be done. The result is a false sense of security.
Log files are not bad, but they aren't sufficient. At least that's what I read.
intel_chris

9/9/2009 3:44 PM
Gravatar Hey Lori,

I think you are being short sighted as well and missing an important component of security (although I suspect you are being controversial for the purposes of generating argument more than anything else).

The goal of security is not to remove all possibilities of an incident - this is unattainable. The goal of security is to reduce the likelihood of an incident occurring and to reduce the impact once an incident does occur, and they will regardless of DLP, web application firewalls, context aware authentication, and full-stack security.

There is no panacea and no guarantee that anything and everything will improve security. This is a misguided concept as well. For example company x could implement all the bullet items you list and fall prey to a malicious attack and company b could do nothing and never experience an incident - here nor there really, but log analysis can provide information that enables faster response times once an incident does occur.

I guess the question to you would be - do you consider incident response, disaster recovery, business continuity and the ability to more efficiently, more effectively and more quickly respond to an incident or breach of policy part of security or not?
Amrit

9/10/2009 3:56 AM
Gravatar I agree that logging to the central logging server in it self is only the beginning & does not improve security. Monitoring & analsing of threats within those events does.

Storing of logs aid in identifying repeat offenders, exploits, or zero day history in order prioritise risk, besides compliance & policy dicatets that one should store logs for a long period of time.
J Quadri
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 4 and 2 and type the answer here: