Honeypots mailing list archives
Re: Legal Question about privacy
From: Steve Barnet <barnet () chem wisc edu>
Date: Thu, 24 Jul 2003 08:21:46 -0500
Hi all, OK, so we're starting to come rapidly to the point of hypotheticals and strained analogies, and I must take full responsibility for starting us down that road. As penance, I'll try to head the discussion down a path that may help provide some guidelines if not answers. The original issue was privacy of communications with respect to honeypots. As I look back on my post, I see that much of it may have been more germane to the IDS list rather than honeypots. But I do think we may have a specific example that could prove instructive: Scan of the Month 28. http://project.honeynet.org/scans/scan28/ In that scan, in addition to the compromise a good chunk of IRC communication was captured as well. It's apparent from the challenge itself that a good degree of sanitizing went on (heck, there's an entire day of traffic missing). In relating this to our current discussion, it seems a clear consensus that the cracker has forgone all (or at least many) privacy rights. In bringing the IRC conversations into the picture it complicates matters because it is not necessarily clear to the users of the channel that part of the link or conversation is being routed through a system that is being used illegally and monitored. If our boy is talking to one of his fellow crackers, we are probably safe in assuming that the other party is aware of this or at the very least would not be surprised to find out that it was true. But what about a legitimate user of the channel? That user (if he/she exists) is entirely unaware of the fact that any monitoring is going on. This brings us back to one of Dan's earlier points that any comm over an unsecured channel is vulnerable to exactly this sort of thing. Very true. So the question then comes: what is the responsibility of a honeypot operator in protecting what privacy does exist? As an initial shot at an answer, I'll throw this out there: honeypot operators should do their best to ensure that any data collected is well and thoroughly sanitized before it is released publicly. Specifically, third parties should be given the benefit of the doubt when deciding how to present data. Perhaps it would be a good idea to create a set of specific guidelines (if such don't already exist) about the types of things to exclude, or how to go about cleaning up data if it's relevant but may skirt the privacy line. It doesn't address the core technical problem that Dan brings up about unsecured channels. However, given that we're unlikely to ever be able to address that issue completely (at least not in the near future), perhaps it will create a social control that is sufficient to pass muster outside the community. That approach seems to have worked reasonably enough with the voice networks which suffer from exactly the same problem (and yes, also suffer quite a bit of abuse). If nothing else, it would create a consistent idea in the community about "best practices" and if/when any excessive violations occur we will generally agree that the activity was inappropriate and atypical of the way honeypot operators work. Thanks for reading this far. Best, ---Steve
Current thread:
- RE: Legal Question about privacy, (continued)
- RE: Legal Question about privacy dave kleiman (Jul 24)
- Re: Legal Question about privacy Valdis . Kletnieks (Jul 24)
- RE: Legal Question about privacy dave kleiman (Jul 24)
- Re: Legal Question about privacy Valdis . Kletnieks (Jul 24)
- RE: Legal Question about privacy dave kleiman (Jul 24)
- Re: Legal Question about privacy Valdis . Kletnieks (Jul 24)
- Re: Legal Question about privacy Jack Cleaver (Jul 24)
- Re: Legal Question about privacy Valdis . Kletnieks (Jul 24)
- RE: Legal Question about privacy dave kleiman (Jul 24)
- Re: Legal Question about privacy Richard Johnson (Jul 24)
- Re: Legal Question about privacy Matt D. Harris (Jul 29)
- RE: Legal Question about privacy Dave Dittrich (Jul 24)
- RE: Legal Question about privacy Chris Shepherd (Jul 31)