Child porn gets by filters; Feds follow

FRAMINGHAM (10/16/2003) - We've had some excitement around my department over the past few weeks involving law enforcement. If you work for an Internet service provider, you are probably familiar with what is called a Section 2703(f) court order.

Title 18 U.S.C. 2703(f) of the Electronic Communications Privacy Act of 1986 contains a provision requiring Internet service providers to take the necessary steps to preserve electronic records and other evidence pending the issuance of a court order or other legal process.

The order is simply a letter from a law enforcement agency requiring a service provider to preserve logs in preparation for a subpoena or search warrant. Receiving such letters is a common occurrence at Internet service providers -- but not at my company.

Suspicions Aired

A few weeks ago, I was called to our general counsel's office, which had received such an order. The letter, typed on fancy letterhead with a three-letter agency logo on top, instructed us to preserve any logs in relation to the network activity of one of our employees.

At the initial meeting, my team and I met with the investigator. He was fairly savvy about technology, which came as a surprise.

He said our employee was using his home computer to access child pornography on the Internet. But the investigator also suspected that the employee was sending pornographic pictures, videos and Web site address information to his e-mail account at work. And the agency had reason to believe that our employee was using his company-issued workstation to access these illegal sites.

I was pretty sure that the employee couldn't use his desktop workstation to access pornography Web sites, since we use content-filtering software that blocks access to most of them. But we had to comply with the order.

Normally, if law enforcement agents want to monitor someone's network activity, they present a Title III wiretap order. That enables investigators to install network-monitoring software that can be configured so they can monitor only a particular person's network traffic.

At our company, however, we already collect network traffic data through our intrusion-detection systems, so a Title III order wasn't needed. We typically keep three months of data, which includes all network traffic going in and out of our company at specific gateway locations.

We have about 20 sensors to gather that data, so I suggested that we filter the data from our network sensors and use our three months of saved data to assemble a profile of the user's network activity.

The investigator agreed, but he cautioned us to maintain the same level of monitoring and to keep all archived data, even if the three-month time period was due to expire. We were not to conduct any additional network monitoring beyond what we do on a regular basis, or he would need to obtain a wiretap order.

Getting the Data

We began to set things up. We identified which network sensor was responsible for monitoring the traffic associated with the employee in question. We configured the port connected to that sensor so it would span the port to which the suspect's workstation was attached. By doing this, we ensured that the only network traffic we were collecting was that going to and from the employee's desktop. We didn't want to provide the law enforcement officials with extra data that might contain intellectual property or potentially sensitive information.

Next, we had to figure out how to sort out the correct archived traffic data. Like most companies, we allocate IP addresses dynamically. The IP address leases are set to expire periodically, so over a three-month period, the suspect would have logged in under dozens of addresses.

Our sensors had collected several gigabytes of data, and we wanted to provide only the necessary data related to the suspect's workstation.

Fortunately, the workstation had a unique NetBIOS network resource name based on the user's name. By knowing the NetBIOS name, we could pull the relevant data from the logs. We ended up copying the data to a CD-ROM, which we gave to the investigator when he returned with a search warrant. We are still required to keep the original data.

After that, we conducted an internal review of the user's network traffic. I was dismayed to discover that he indeed been e-mailing himself pictures and other contraband. What's more, he had used Yahoo chat groups to share his illegal materials. Our filtering software didn't block access to those groups, since the names of the groups didn't match any of the filters we had installed on our URL-filtering application. The employee had also used his desktop to e-mail pictures and video clips to others by way of a Yahoo e-mail account.

We confiscated his desktop computer and gave the hard drive to the investigator. Our human resources department is in the process of terminating this individual's employment, and I'm sure that there will be an arrest at some point.

Now that this episode is behind us, we plan to review the configuration of our filtering software and our intrusion-detection system to see what changes we can make to prevent this type of activity from recurring. In this case, the user was accessing inconspicuous chat areas. Since we aren't blocking access to Yahoo chat rooms, the challenge will be to come up with a way to minimize false positives and performance issues while still preventing unauthorized use of our resources. w What Do You Think?

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at


Security Log

Security Bookshelf

Kerberos: The Definitive Guide, by Jason Garman; O'Reilly & Associates, 2003

Kerberos is one of those subjects that I always run across on certification tests, and it's mentioned lightly in authentication or single-sign-on discussions. Although Kerberos has been adopted into a majority of operating systems, including Microsoft's Windows and Active Directory, I have only a limited understanding of it, and I haven't found much documentation on it.

This book is a big help. It discusses Kerberos' origins, security and a few advanced topics such as cross-realm authentication. I especially appreciated the detailed implementation chapter, which explains how to install Kerberos within the Unix environment. If you're looking to expand your knowledge or simply need a good authentication/access-control reference book, O'Reilly has done it again.

New BEA Security Architecture

Middleware maker BEA Systems Inc. in San Jose has announced a distributed security architecture, WebLogic Enterprise Security. WLES is designed to simplify application security for companies with heterogeneous application environments. Rather than managing redundant security features within each application, BEA customers will be able to use WLES for centralized security policy management through a Web-based administrative console. WLES takes advantage of technology from CrossLogix Inc., a Redwood Shores, Calif.-based developer of end-user access authorization software that BEA bought last February.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about BEABEA SystemsGatewayMicrosoftO'Reilly & AssociatesProvisionReillyYahoo

Show Comments