Are ISP's or enterprises accountable for illegal online activities?

[Cooky]

So far we've been supporting our guest wifi service via ticketing system.
We'll then document the guest's identity, which employee brought that contractor/guest in, and then create guest accounts.
We've been tasked to make the process faster & easier.

One of the VP's asked why we don't make the guest experience just like coffee shop or hotels, where the patrons can just get on the wireless w/o any credentials.

We were shocked at first, but then tried to educate him on reasons of security, liability, etc.

So my questions are:
1. Are ISP's or enterprises accountable for illegal online activities?
If our employees distribute copyrighted music or movies, would the music or movie industry sue the company, and actually win the case?

Please provide hard facts, preferably w/ reference & links, and not just your opinion on how it should be.
============
2. If the answer to the above question is yes, they are accountable, then how do coffee shops , hotels, or other places that offer wifi w/o knowing who's on their networks deal w/ the law suits & regulations?

If any of you have worked on similar cases, please share your experience, and how you dealt w/ it.

Thank you!

 

[JackMDS]

We were shocked at first, but then tried to educate him on reasons of security, liability, etc.

We are shocked that you think that you can solve such an issue through a public Forum.

That is a complicated issue that should be handled by the Legal Dep./Counselor of the specific corporation.

 

[drebo]

Generally, the network owner/operator is responsible for what goes on on the network.

If you are opening it up, you should consider using a captive portal with RADIUS to at least capture the users' information before authorizing his MAC via RADIUS. It shouldn't be too difficult. After that, definitely look in to content and application filtering.

Palo Alto can do both of those things at the network level, as opposed to the AP level...though it's not necessarily bad to do the captive portal redirect at the AP (or controller).

 

[Cooky]

Thank you both for the quick reply.

Jack - we thought about talking to our Legal, but it would've taken too long.
We're trying to come up w/ a policy based on info that's available to us, w/o having to involve too many departments & opinions.

drebo - what information of a guest can be captured via the captive portal?
Our existing guest solution already has a captive portal, but that's used to authenticate guests after we create an account for them.

It sounds like what you're suggesting is something different...if we let a user through, after he/she fills out the info on the portal, any info is based on voluntary basis, and may not be accurate.
I've seen hotels do something similar - asking for your room number.
I was able to get online by providing a fictitious number (something like 999).

As far as content & app filtering, that's a different issue that we'll tackle as a separate project.
We were impressed by Palo Alto's next-gen firewall a few years ago, when the former Netscreen founder left Juniper and founded PAN.
Overall though it's a decent solution if you're looking for an multi-role device (firewall, content, DLP, and VPN).
However, it has some scalability issue for large enterprises.

 

[Railgun]

Just use checkpoint then for content/app/URL filtering. It works well, if not over restrictive. Done and done.

Long story short, create an acceptable use policy. Only you can define that.

 

[Cooky]

Has there been any cases where a company gets sued for illegal activities that occur over their networks, and actually had to pay up?

Our content filter strategy is something we'll handle as a separate project due to the scale & complexity of the user/department requirements.

 

[drebo]

Thank you both for the quick reply.

Jack - we thought about talking to our Legal, but it would've taken too long.
We're trying to come up w/ a policy based on info that's available to us, w/o having to involve too many departments & opinions.

drebo - what information of a guest can be captured via the captive portal?
Our existing guest solution already has a captive portal, but that's used to authenticate guests after we create an account for them.

It sounds like what you're suggesting is something different...if we let a user through, after he/she fills out the info on the portal, any info is based on voluntary basis, and may not be accurate.
I've seen hotels do something similar - asking for your room number.
I was able to get online by providing a fictitious number (something like 999).

As far as content & app filtering, that's a different issue that we'll tackle as a separate project.
We were impressed by Palo Alto's next-gen firewall a few years ago, when the former Netscreen founder left Juniper and founded PAN.
Overall though it's a decent solution if you're looking for an multi-role device (firewall, content, DLP, and VPN).
However, it has some scalability issue for large enterprises.

Well, the info will be voluntary basis, yes. There's no getting around that. The point, though, is that you're trying. But, if you have a captive portal that requires the user to enter in name, company, etc, and you already have building sign-in, you can correlate the network access to the building access and even if they used ficticious info, you can still pretty much figure out who it was.

The point is that you're doing your due diligence and creating an access log. The goal is to create plausible deniability for any of your own employees if anything illicit is tracked back to your organization. You can say "so and so logged in to our network at such and such time, here is his info" and be done with it.

The Palo Alto is nice in that the logs it creates are extremely complete and very useful and the content filtering is extremely customizable. If you combine that, your captive portal information (you'd have to write this yourself and use your own database to store the info), and building access logs, you can create a very complete picture of which contractors/visitors visited which sites.

Basically, the defense of "well, it was open wifi" doesn't fly anymore. You need to maintain network access controls and you need to make sure that it's as difficult as possible for users to log in.

I like the idea of creating a new AD or RADIUS user for each guest, and then having them use those credentials to log on to the wireless network. That sounds like what you're doing now...but it can be extremely high maintenance. Perhaps you should focus your efforts on making that user generation process simpler or something the receptionist can do when the user signs in. Not sure about the rest of your business policies as they relate to that.

But, you definitely want to log access and you definitely want to filter explicit content.

 

[theevilsharpie]

I haven't used free WiFi in a while, but every system that I've ever used (including Starbucks) has put up some type of captive portal that requires you to agree to their terms of use before letting you on their network. I'd imagine that they also log your usage, to protect against this very type of thing.

 

[drebo]

Has there been any cases where a company gets sued for illegal activities that occur over their networks, and actually had to pay up?

Our content filter strategy is something we'll handle as a separate project due to the scale & complexity of the user/department requirements.

I'd definitely recommend Palo Alto for that, then. You can define policies based on AD users/groups (not OUs, though...) or based on source IP addresses. It also has true content filtering, in that you can actually filter specific types of files from being transferred. You can also use it to inspect SSL traffic (as long as you have your own trusted root cert installed on your users' systems). All of that is configurable for different user groups, etc.

My only gripes with the PAs is lack of GRE tunnel capabilities and lack of complex traffic shaping (it doesn't have a similar technology to Juniper's virtual channels, for instance.)

 

[Cooky]

Thank you all for the replies.

Well, the info will be voluntary basis, yes. There's no getting around that. The point, though, is that you're trying.
...you can correlate the network access to the building access

Is this good enough for most places?
We have ~130 locations, and unfortunately physical security (building access logs) policy isn't consistent.

The goal is to create plausible deniability for any of your own employees if anything illicit is tracked back to your organization.

Our current solution already prevents employees from getting on guest wifi, unless we open the flood gate, and allow anyone to get on, as long as they fill out the portal form.

you need to make sure that it's as difficult as possible for users to log in.

Unfortunately that's our VP's beef w/ it.
He wants it to be as easy as possible, hence the reference to coffee shops, or hotels.

I like the idea of creating a new AD or RADIUS user for each guest, ...but it can be extremely high maintenance. Perhaps you should focus your efforts on making that user generation process simpler or something the receptionist can do when the user signs in.

Creating guest accounts isn't that high maintenance w/ the existing solution.
Current flow is an employee emails or calls the Call Center, and a Support Analyst can create an account in as little as 30 seconds.
I'm quite happy w/ this, but VP wants something more...self provisioning or open access.

But, you definitely want to log access and you definitely want to filter explicit content.

Definitely; this will be handled by a content filter solution.

I'd definitely recommend Palo Alto for that, then.

Thanks, we already looked into PAN a few years ago, but they had scalability issues.
3 years ago they claimed their PAN firewall can do 10G, but only if you don't turn on L7 inspection, which is actually their main selling point. When L7 inspection is on, the supported bandwidth is cut in half (5G)...this is assuming you don't turn on DLP, VPN, etc.
This is not going to work, as we have two 10G Internet circuits, and that alone just makes the PAN solution not meet the requirement.
Also, the way they track access is by looking up the mapping between source IP & username in AD logs.
At the time we didn't think it was going to be able to do it fast enough based on our total user count & amount of traffic.
Perhaps they've beefed up their solution since then??

I haven't used free WiFi in a while, but every system that I've ever used (including Starbucks) has put up some type of captive portal that requires you to agree to their terms of use before letting you on their network. I'd imagine that they also log your usage, to protect against this very type of thing.

Thanks, but how do they know who you are?
Anyone (including malicious users) can just click through the agreement / acceptable policy, and get on the network.
After an incident has already occurred, law enforcement calls and asks who did it, and we would have no clue, if we just allow open access.

 

[imagoon]

I think most of them throw up the EULA (ie Starbucks) for their protection. Once you can show reasonable doubt that it was a customer and not Starbucks itself that hacked the Pentagon, Starbucks gets out of the case. It doesn't always matter that they can't exactly identify them.

 

[drebo]

The other option is to update your ticket system so that your users can get an automatically generated temporary "access PIN" that they can give to their guests. Then, via captive portal, you can authenticate that guest. From there, you have a record of that users' IP address and the employee that created the PIN. From there you can identify which guest it was. Your content filter would track the IP assigned to the guest and you'd know which guest it was because you'd have their PIN in a database as well as their IP address.

Should be relatively simple to set up.

 

[Lithium381]

For a free solution, look at using Untangled firewall, i believe it does captive portal, antivirus checking, URL filtering etc . . . .if not a Palo Alto has a lot of good functionality...