GDPR and IETF's INTAREA Recommendation for sysadmins

[viktorix]

Hopefully everyone is aware of GDPR by now, what is new that I wanted to bring to OSSEC's attention is the recommendations from IETF's INTAREA for sysadmins to help comply with GDPR.

It only came out on April 22. So it's new. You can see their recommendation in full here: An update to RFC6302 on Logging Recommendations for Internet-Facing Servers

Long story short, these are the main bullet points:

  Providers of internet-facing servers

  1. SHOULD only store entire incoming IP addresses for as long as is
  necessary to provide the specific service requested by the user.

  2. SHOULD keep only the first two octets (of an IPv4 address) or the
  first three octets (of an IPv6 address) with remaining octets set
  to zero, when logging.

  3. SHOULD NOT store logs of incoming IP addresses from inbound
  traffic for longer than three days.

  4. SHOULD NOT log unnecessary identifiers, such as source port
  number, time stamps, transport protocol numbers or destination
  port numbers.

  5. SHOULD ensure adequate log access control, with suitable
  mechanisms for keeping track of which entity accesses logged
  identifiers, for what reason and at what time.

  It is RECOMMENDED that deviations from the above practices are
  carefully documented and communicated to subscribers.

As you can see, 2 directly affects OSSEC and all other HIDS. Since OSSEC watches logs, including access logs, it would be impossible to block (Active Response) IPs if they are annonymized. Moreover, item 4 on the list means that logs may not have port numbers.

Of course, this is up to the sysadmin to implement these recommendations or not. But to be GDPR compliant, it would behoove us to follow recommendations.

This also affects OSSEC logs. Thoughts?

Wanted to bring this up and start a discussion on this.

[atomicturtle]

Its definitely down to the environment its deployed in. For starters OSSEC is processing the events from something else that is capturing the IP, so its kind of operating in a tertiary capacity there.

There would be other regulated environments (HIPAA, PCI-DSS, SOX/GLBA, NIST-800-53, etc) where auditing requirements would directly conflict with this. Who or what processed PHI/PII/PAN is definitely in scope and would require tracking that information for years (and in some environments, forever)

That said you could still use AR, and set ossec to not log anything.

[ddpbsd]

2: I guess we could create a sanitize_ip(), sanitize_username(), etc. Then only run them if <gdpr_sanitize>yes</gdpr_sanitize> is set.

3: Rotating logs and whatnot would still be left as an exercise for the user.

4: That's just crazy. Maybe gdpr_sanitize should just stop logging anything? I haven't seen anything form other open source projects on how they're handling this (but I haven't really looked).

5: Not part of OSSEC's feature set.

[atomicturtle]

Not to mention isnt 5 in conflict with 1,2,3, and 4?

[zvanderbilt]

I think 5 can be mostly accomplished by setting restricted permissions on log files. ie owned by root, not world readable, etc. which is how it is by default I believe on ossec logs. So long as the user has adequate sudo and root logging then that should suffice.

But like ddpbsd said it's just not even in the scope of OSSEC's current features. There could totally be a rootcheck scan for gdpr compliance in the future though. #goals

[atomicturtle]

Its a great discussion topic to capture here one way or the other, so thank you for this. Im sure we're not the only people to have considered this topic, and a thoughtful, professional chain of discussion only adds to it. Maybe we can make this a blog topic?

[sempervictus]

We deal with global clients caught up in this mess quite often, and when it comes to OSSEC, the business logic we suggest looks something like this (we are engineers, architects, and security practitioners, not lawyers by any stretch of imagination):

1 - IP addresses are needed for years, if not forever, to see if something which comes on a blacklist from identified threat today communicated with client systems in the past. 
2 - N/A because the point of all IDS' is subject identification, not generic stats like web hosts. If the EU balks, and sues, countersue for every device they use which does the same thing. they can't change firmware. (Our clients can generally afford to do this, for everyone else, I'd wait till they slap the arrogance off of the EU commission a bit for hypocrisy).
3 - See #1, note the word SHOULD.
4 - There are very few identifiers which are not necessary, we can offer a level of operational logic to support that, they have the technical knowhow of a lemming based on the regs, and aren't likely to be able to argue the opposite.

IDS is like any forensic process, all possible evidence must be collected and passed in chain of custody (a codified term and process) to have the data needed to prosecute the offender, investigate associates, and fight subsequent appeals - the data almost never dies because it's needed until final resolution and maybe past that for the soc. If they want to argue the opposite, then Europol can be the first to abide by those regs. Until then, they keep themselves open to legal challenge because they don't abide by the laws of their own jurisdiction. While I'm all for abiding local customs and courtesies in theater, this is akin to a custom requiring one disarm before entering an enemy city. Its "counterproductive" to put it mildly in terms of operational efficacy. I'd watch what the big vendors do, they can't sell at all in the EU if they abide by this (try a firewall/NIPS which only works on /24s, see how far you get). Lastly, the project serves global needs. If the EU really does try to enforce these constraints, or some crypto bypass/backdoor legislation, we just won't be able to work there till after the breakup of the bloc anyway.