Full Content Monitoring as a Wiretap
I received the following question today:
When installing Sguil, what legal battles have you fought/won about full packet capture and its vulnerability to open records requests from outside parties? I am getting concerns, from various management, regarding the legal ramifications of the installation of a system similar to Sguil in the state government arena. Do you have any advice for easing their worries? I know how important full data capture is to investigating incidents, and I consider it of paramount importance to the security of our state that we do so. Are there any legal precedents that can be cited?
Before I say anything else it is important to realize I am not a lawyer, I don't play one on YouTube, and I recommend you consult your lawyer rather than listen to anything I might say.
With that out of the way, I have written about wiretaps a few times before. Let me get these generic wiretapping issues out of the way before addressing the question specifically.
The pertinent Federal law is 18 U.S.C. §2511.
A great place to look for commentary and precedents on digital security issues is Orin Kerr's Computer Crime Case Updates. This search for wiretap may or may not be helpful.
Finally, for recent commentary by a lawyer (but not your lawyer), I recommend Sysadmins, Network Managers, and Wiretap Law (.pdf slides) by Alex Muentz. These notes from his LISA 2006 talk are helpful too.
I think the key element of the question originally posed was full packet capture and its vulnerability to open records requests from outside parties. It sounds like the question asker is worried about discoverability of full content data. I touched on this briefly in The Revolution Will Be Monitored.
My answer to this problem is what I would consider both practical and technically limiting: do not store more full content data than you need. For any modern production network, capturing and storing days or weeks of full content traffic can be an expensive proposition. For example, in one client location I have about 200 GB of space available for full content storage. That space allows me to save a little more than 10 days of full content, even with fairly draconian BPFs limiting what is stored. If for some reason I needed to produce that data to management or attorneys, I could only provide the last 10 days of information. If the event in question occured prior to that period, I just don't have it.
I do know of some locations that operate massive storage area networks to save TBs of full content. I do not advocate that for anyone but the most specialized of clients. I do recommend collecting the amount of full content (if possible, legally and technically) that works for your investigative window. For example, if you have a requirement to review your alert and session data such that you are never more than 5 days past an event of interest, you might want to save 7 days of full content. From an investigation point of view, more is always better. From a practical point of view, it might be too costly.
Remember that any network data collection should be considered a wiretap. Full content is the form of network data that most resembles a wiretap.
With respect to session data, I recommend saving as much of that as possible. In practical terms it comes down to the amount of space you're willing to devote to database files. At the same client I am collecting as many sessions as I can, without filters. 30 days of such session data is producing about 20 GB of uncompressed MySQL table files. As you can see I can store many more days of session data as compared to full content data. That means much more session data is discoverable. I might choose to limit storage of that session data to meet whatever guidance corporate legal counsel might provide.
Session data is like pen register/trap and trace data, because it does reveal content. I still treat it like a wiretap but it probably does not meet the same standards.
Event data, i.e. IDS alerts, take so little space as to not require any real storage consideration (compared to full content and session data). Therefore, the primary limiting factor is legal and policy, not technical.
I think anyone who really wants a better answer would do well to check our Prof Kerr's list, and potentially ask him. Alex Muentz would be another good resource.
When installing Sguil, what legal battles have you fought/won about full packet capture and its vulnerability to open records requests from outside parties? I am getting concerns, from various management, regarding the legal ramifications of the installation of a system similar to Sguil in the state government arena. Do you have any advice for easing their worries? I know how important full data capture is to investigating incidents, and I consider it of paramount importance to the security of our state that we do so. Are there any legal precedents that can be cited?
Before I say anything else it is important to realize I am not a lawyer, I don't play one on YouTube, and I recommend you consult your lawyer rather than listen to anything I might say.
With that out of the way, I have written about wiretaps a few times before. Let me get these generic wiretapping issues out of the way before addressing the question specifically.
- Understanding Legal Issues of Network Monitoring
- Excellent Coverage of Wiretapping Issues at News.com
- Two Great Wiretapping Articles
The pertinent Federal law is 18 U.S.C. §2511.
A great place to look for commentary and precedents on digital security issues is Orin Kerr's Computer Crime Case Updates. This search for wiretap may or may not be helpful.
Finally, for recent commentary by a lawyer (but not your lawyer), I recommend Sysadmins, Network Managers, and Wiretap Law (.pdf slides) by Alex Muentz. These notes from his LISA 2006 talk are helpful too.
I think the key element of the question originally posed was full packet capture and its vulnerability to open records requests from outside parties. It sounds like the question asker is worried about discoverability of full content data. I touched on this briefly in The Revolution Will Be Monitored.
My answer to this problem is what I would consider both practical and technically limiting: do not store more full content data than you need. For any modern production network, capturing and storing days or weeks of full content traffic can be an expensive proposition. For example, in one client location I have about 200 GB of space available for full content storage. That space allows me to save a little more than 10 days of full content, even with fairly draconian BPFs limiting what is stored. If for some reason I needed to produce that data to management or attorneys, I could only provide the last 10 days of information. If the event in question occured prior to that period, I just don't have it.
I do know of some locations that operate massive storage area networks to save TBs of full content. I do not advocate that for anyone but the most specialized of clients. I do recommend collecting the amount of full content (if possible, legally and technically) that works for your investigative window. For example, if you have a requirement to review your alert and session data such that you are never more than 5 days past an event of interest, you might want to save 7 days of full content. From an investigation point of view, more is always better. From a practical point of view, it might be too costly.
Remember that any network data collection should be considered a wiretap. Full content is the form of network data that most resembles a wiretap.
With respect to session data, I recommend saving as much of that as possible. In practical terms it comes down to the amount of space you're willing to devote to database files. At the same client I am collecting as many sessions as I can, without filters. 30 days of such session data is producing about 20 GB of uncompressed MySQL table files. As you can see I can store many more days of session data as compared to full content data. That means much more session data is discoverable. I might choose to limit storage of that session data to meet whatever guidance corporate legal counsel might provide.
Session data is like pen register/trap and trace data, because it does reveal content. I still treat it like a wiretap but it probably does not meet the same standards.
Event data, i.e. IDS alerts, take so little space as to not require any real storage consideration (compared to full content and session data). Therefore, the primary limiting factor is legal and policy, not technical.
I think anyone who really wants a better answer would do well to check our Prof Kerr's list, and potentially ask him. Alex Muentz would be another good resource.
Comments
(I also got a bit of "feedback" regarding contacting the AAG directly. My boss felt that was a prerogative of his boss, or his boss's boss. Everything winds up at OSI Layer 8.)