Logging vs. Privacy, Data Protection Laws & Codetermination Regulations

Are you keeping track of how many organizations have been breached and their data stolen this week?

I stopped counting.

But it is very interesting to see how different organizations react to data breaches. Those who obviously don't have proper incident handling & response procedures mostly are hit much harder, detect the breach much later and in addition to that get very bad public reputation for it after the breach becomes public.

Those organizations who detect breaches or ongoing attacks early and respond to them appropriately are able to mitigate the impact of that attack.

Those who are able to tell what exactly happened, how it happened, when it happend and how they were able to stop it, earn credibility and good reputation.

So being able to detect early and respond professionally is really a significant competitive advantage to any business.
The first example results in loss of reputation and loss of trust. The second results it good reputation and trustworthiness. 

Of course this is kind of an idealized view. You can still fail to properly communicate your professional incident response if your internal communication is bad or if your public relations department fails to translate all this to the public and to customers.

And of course this is also a somewhat biased point of view from within our industry. Average Joe might not have an understanding of what we in the infosec industry think is good incident response and why this is good for the customer, too.
A customer might just think "oh my bank or webshop has been attacked so I am at risk. I'll better move to another bank or vendor who has not (yet) been attacked".

But let's just agree on that good incident handling & response is a vital thing today.

How do we get there? Right! We have an incident response plan, we ideally have a skilled staff and we have....information.

Information about what's going on on the network, on the systems, within applications, in databases and so on.

Where do we get that information? We get it from *cough* intrusion detection systems, netflow-collectors, and from system logs, firewall-logs, proxy-logs, account-logs, logs, logs, logs.

How do we collect and store all that data? Right! With a logmanagement solution. Be it a homegrown solution, based on open-source software or a commercial solution. 
But what do we log, how much do we log, how long do we store logs and are we even allowed to log all of that data?

In the US this seems to be not that much of an issus, but in Germany we have data protection laws that are ignored too often but can be prohibitive for logging in big organizations. Then we also have codetermination regulations that can be very prohibitive, too in some cases.

This is what I would like to discuss a little bit and please feel free to comment on that. Share your opinions and experiences!

Information security is incredibly complex and difficult to grasp for those who are in charge to taking vital decisions. In Germany the "internet community" (whatever that is) just told politicians that their data retention law is disproportionate and bad and that they should respect the people's right of privacy. Big organizations have data protection officers. Those are now highly sensitized when it comes to data protection. If they have to chose between logging more or less they would always opt for logging less and then still ask you to anonymize the data. 

Then you have codetermination regulations (if I got this translation of  "betriebliche Mitbestimmung" right). Logging in many cases is equal to or enables you to do workplace (performance) surveillance - which is not allowed.

What is missing though is a very clear regulation or law regarding accountability and traceability for organizations that store personal identifiable or other sensitive information. We need a regulation or law that oblige organizations to be able to prove who had access to what data for at least as long as this data is being stored. For banks and financial institutes there are very specific regulations (SOX, Basel II) which effectively oblige banks to store financial transaction logs for a certain amount of time (I think two years or so) and in a certain fashion so that data integrity is warranted.

So what would you do as a CEO of a large german organization. You see politicians being bashed for their data retention plans, your work council/committee tells you they don't like you to log extensively because of potential workplace (performance) surveillance and your data protection officer tells you to log as little as possible and in addition to that to anonymize the data (e.g. delete source ip addresses in log of  public web-servers). Only your CISO tells you (the CEO) that you need to log extensively because when (not if, there is no if)  something happens, this is your only chance to reconstruct what really happened - or to detect the attack before something really bad happens.

We have a conflict of interests here and very little help on the side of our CISO and CEO. 

It is always the same: there is just no simple answer to a complex problem. You have to use your brain and balance risks.

You can ask a lawyer to tell you something about evaluation of the higher (more valuable) legal interest or right.

Another good thing to do is threat modeling on a corporate and strategic level. Ask your data protection officer if he or she will stand up and tell the customers that "well because of data protection needs and codetermination regulations we did not think it appropriate to log who had access to your personal identifiable information so we just can't tell if your data was stolen or not".

Well, maybe you should ask that question in a less provoking manner but it is really a good and vital question. Will you stand up in the public with your pants down or would you rather be able to show and prove that you have things under control - always had.

So how to get there? 

Go ahead and write a log-management policy. Begin with your top directive and primary goal for your log-management: it must enable you to detect attacks and even more important enable you to tell what exactly happened.
Differentiate between high-value data (like PII and other sensitive data like business plans, your corporate IP etc.) and lower value data. For sensitive data and assets you need more detailed and longer logging (e.g. two years full logs), more secure and tamper-proof logging, for less sensitive assets and/or data you can use a shorter data retention period like six months.

Your policy should cover what is being stored and how long, who has access to what data and in which case.

But don't get too granular - keep things easy. Best thing would be to store everything for a fixed amount of time.

If personal identifiable information in logs (like IP-addresses or usernames in account-logs)  are a problem, use a reversible solution that anonymizes or pseudonymizes the data. You could use a four-eyes policy in case you have to reverse the pseudonymization, maybe require the data protection officer to type in his part of a multi-part password or passphrase. 

If you are using or planning to use a SIEM for data correlation and attack detection, make sure that your logmanagement policy allows for the appropriate amount and quality of data to be stored for an appropriate timeframe. Otherwise a SIEM solution will just not work and be pointless. For operational security monitoring with a SIEM you need the original (not anonymized or pseudonymized) data at least of the last few days. Pseudonymization or anonymization should only occur for longtime storage.

 Today, after all the reports about data breaches since 2008 I would recommend to store at least half a year of complete log-data, because many breaches have only been detected months after the initial attack, sometimes even a year. And imagine how bad it is to not only detect a breach this long after the fact but then not even being able to tell what exactly happened and what the impact is. If you are not allowed to store the data needed for a comprehensive forensic analysis, make very clear to your upper management what the consequences for the business could be in case of a data breach. 

Views: 209


You need to be a member of Dissecting The Hack to add comments!

Join Dissecting The Hack

Latest Activity

SUR3SH0T updated their profile
Oct 20, 2020
Anton Vyacheslav is now a member of Dissecting The Hack
Dec 9, 2018
bernardorichard updated their profile
Nov 28, 2018
Sam Mccalla is now a member of Dissecting The Hack
Nov 19, 2018

Stratagem 13 News Feed

© 2021   Created by Marcus J. Carey.   Powered by

Badges  |  Report an Issue  |  Terms of Service