Logging, Government Enacted Data Retention & Data Privacy Protection

I am lost - lost in an area of conflict.

 

Not that there were no solutions to solve the conflict.

In fact the conflict isn't as bad as it seems in the first place - at least this is my opinion.

 

You may be asking yourself exactly what am I talking about.

 

I am talking about the fact that we tell politicians and those in charge of IT:

a) how important data privacy protection is,

b) how data retention and excessive surveillance by gov. agencies create an Orwellian state or worse,

c) that we need to log everything and need IDS, SIEM and other stuff for OPSEC.

 

The first point is just sinking in with politicians.

They understand that data privacy protection is important.

In Germany there are - at least in theory - strict data privacy protection laws. In theory.

So if you suggest extensive logging for security reasons your CISO will ask your privacy protection officer and your privacy protection officer will probably react like with something like this:

"Don't store anything because you may only store what is needed for billing purposes or as much as is needed to comply with other laws and regulations."

 

Ah yes, and public IP-addresses of clients who visit your website are of course personal identifiable information which has to be anonymized or deleted as soon as possible; which is after few days if you're asking your privacy protection officer - maybe a week if you're lucky.

 

In fact, in Europe it is kind of popular right now for the sake of civil liberty to say "we don't log". 

I understand and respect this. It's the pursuit of the governments to enact Orwellian data retention and surveillance laws that are wrong, not those trying to preserve civil liberties and the right to inform and express themselves on the internet without having to fear repercussions.  

 

But for a company or large website offering services to customers, not logging would be stupid and negligent and would bite you in the ass sooner or later.

 

So, we are left asking ourselves the key questions:

How to strike a balance? 

How to communicate solutions? 

How to convince those who are in charge? 

How take away their fears? 

 

The main problem *is*, in fact, a communication and education problem.

 

This is where I fail. This is where the infosec industry fails I think.

Don't get me wrong: I don't fail to explain the implications and solutions - I would *love* to do that.

I fail at getting the attention of those who have to understand the implications of today's threat landscape, the need for in depth security and adequate monitoring and security testing and the solution to what at first looks like an area of conflict.

 

But is it really such a bad conflict? I don't think so! My friends in the USA will most probably not be able to follow my train of thought here because in the US a slightly different mentality prevails when it comes to logging and data retention. Please correct me if I am wrong.

 

Leaders have to understand the difference between government enacted surveillance and data retention of data traversing public communication infrastructure and the need of adequate logging within your *own* organization for your *own* security (not for government surveillance).

Of course there is an area of conflict where both overlap. 

If your government obliges you to give them your logs (without court order and without justified reason like a capital offense or *real* case - repeat a *real* case of national security), maybe you are better off *not* logging too much but only as little as you are obliged to by that same data retention law? 

 

I think this is bullshit! (disclaimer: my own personal opinion)

 

So what are the solutions?

 

1.) Log as much as you can and do real log management 

2.) Create policies and deploy organizational processes that regulate and manage

a) How long each type of log data is stored

b) How, when, in which cases and by whom log data may be accessed

c) How access to log data is being logged and audited

d) How and when log data is anonymized or reversibly (four-eyes principle!) pseudonymized 

e) How log data is encrypted/decrypted and who holds the keys, how they can be recovered etc.  (keymgmt)

e) Which log data may be passed on to law enforcement and gov. agencies in which cases and following which procedures

 

The information security industry only begins to understand that their log management *solutions* will have to support all of this. Those who sell logmgmt, surveillance technology (e.g. deep packet inspection, ssl mitm gateways), data-mining tools, BI tools, SIEM or whatever have traditionally not been very interested in data privacy protection and the like.

Last thing I heard from various log management and SIEM vendors was always that: 

"We see a need for support of granular retention periods for log-content, address/accounting data and statistical data. We also see a demand of anonymization, encryption, four-eyes principle and the like." Great! We have come that far.

Those principles have been in the CISSP study program for years! (disclaimer:  I am not a CISSP ;-) ) 

This means that vendors have only just begun to put those features on the roadmap along with many other features that may or may not be included in one of the next versions of their products.

And if they are implemented, I am sure it will be done half heartedly just so they can check a box on the feature list. </cynicalrant>

For the time being, the only technical solution will be: BYO 

But if we only already were at that point! First, the awareness, communication and education problems have to be solved.

 

As always I would *love* to read your feedback and your ideas on that topic. What do you think? How do you handle that stuff or is it a non-issue for you? How can we raise awareness to the topic? How to reach out to leaders so they lend you an ear?

Thanks for reading through another of my lengthy blog-posts. :)

 

Views: 165

Tags: SIEM, data, logging, logmanagement, privacy, protection, retention, surveillance

Comment

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

Join Dissecting The Hack

© 2014   Created by Marcus J. Carey.   Powered by

Badges  |  Report an Issue  |  Terms of Service