We work in an organisation which is supposed to be HIPAA compliant. Security is a big concern for us. We've been tasked to find out if any user is using anonymous proxy in the network.
Is there a way we can find if Tor is being used inside our corporate network domain? We're using Symantec client protection. VPN is provided using Cisco.
You can use a list of Tor (uplink) nodes, add this to the outgoing firewall, setup a task to update this once a day and you'll be good. But Tor can also be used over a HTTP(S) proxy, so you will have to detect proxies as well.
I am not sure if this is going to help you secure anything. As long as there is a connection to the internet, it would be possible to bypass these kind of security measures. You could end up spending endless time and energy to prohibit all kinds of proxies, VPN's, SSL tunnels and such. The advice is to just make sure they cannot do any harm by protecting whats important to your business, and leave users be. For example separate the network in compartments, use subnets, VLANs, DMZs and require authentication and authorization on private networks. Keep the important stuff in one zone, while allowing networking without restrictions on another. And so on...
I believe your major concern should be that:
using anonymous proxy in the network
Is a bad assumption. I would straight away ask:
In which network?
Yorick already touched this point but I'll be more blatant.
HIPAA is mostly about privacy of the data in your production system and therefore in the network that is used to connect to the production system. You should have the control of what all machines connecting to this network can do. In other words, these should be company machines managed by the company, and provide the software that is needed to deal with the production system. No other machines should connect to this network, this includes VPN to the production network (which should be best avoided if possible).
A network for your employees that do not connect to the production system, e.g. a development network or office wifi shall be separate from the production network. You only need to explicitly show that the networks are separate (preferably with separate hardware, 802.1Q VLANs are subjects to a couple of attacks if badly configured). The machines in these networks are of no concern for the production system as long as they never connect to it (they should not!). Moving anything into production shall anyway have a QA/QC procedure in which the security of the code/configuration/another change is evaluated.
It is worth noting that the development network containing the development machines shall never see any production data. If your production data is to be safeguarded (e.g. for patient privacy as in HIPAA) you must anonymise all data in development/test setups. Having a secured production environment and then dumping production data into an unsecured network would be just silly.
The only way you can be relatively sure Tor is not in use on the network is to inspect every device on the network and ensure that Tor is not installed or running on any of them. This could require so many man-hours that it may as well be impossible. And you might miss it anyway.
You can attempt to detect the use of Tor by watching for traffic to any of the hardcoded directory authorities, to which all Tor clients will always connect (with an exception, see below). There are usually less than a dozen of these.
You could also attempt to detect traffic to any of the thousands of guard nodes, but that may put a lot of strain on your IDS. Detecting directory authority traffic requires watching for only a few IPs and there will be traffic to these authorities even for otherwise idle clients.
The big exception is when Tor has been configured to use a bridge. These are explicitly designed so that Tor does not communicate directly with any of the normal Tor nodes or directory authorities. Instead they communicate with an unpublished bridge address. Nation states have difficulty detecting these connections; if one is in use on your network, you have pretty much no chance.
What you should be doing instead is more carefully controlling access to and from the network in general. Only traffic which is actually needed should be allowed to and from any device where PHI may be accessed or stored. This means you need to default-deny in both directions, incoming and outgoing, also segregating networks where PHI is present from other networks. It sounds like your current firewall egress policy is default-allow, and blocking things in a default-allow configuration is like punching holes in the sky.
Preventing the user from installing/using software that has not been approved by the company, by enforcing software policies on employees machine will suffice, combined to network authentication such as only those policy-compliant machines can access the network. This makes the workstation nearly a simple kiosk machine. In finance and healthcare industry, it should not be considered inappropriate to enforce a kiosk mode to operational employees.
The inability to run a software that may connect to Tor is the key to prevent users from using Tor, if browser (e.g. onion.to proxying) is not part of the threat. But normally you would have a whitelisted list of sites available in protected environments.
This, in the real world, often collides with the needs of IT staff. In most companies, the ability for the IT, who are not necessarily software developers/engineers, to run any software or to write custom scripts is a requirement. For sake of discussion, let's assume that is the case.
Of course you cannot prevent your sysadmin to run Tor and you can't also lock his machine down to a kiosk for just that "threat", otherwise you will prevent extraordinary out-of-process activities such as fixing problems with machines or network. In this case, I would recommend to employ a policy such as the sysadmin machines with privileged software configuration are normally connected to a non-sensitive network, and eventually Internet. If a sysadmin needs to access the sensitive network where protected information is stored, then he/she shall phisically connect his/her laptop to a different plug, and record the event into an audit trail. Such audit may also be accomplished by a comment on a support ticket "I am gaining access to machine 10.100.200.10 in order to complete the task".
In short words, preventing anyone from using Tor is a strict requirement that is difficult to enforce, however a reasonable reinterpretation of the requirement should satisfy any regulator by adopting the security principle that users must be able to run only the least minimum set of software programs to accomplish their duties (a variation of the least minimum privileges principle).
And anyway Tor itself is not a threat, it is a medium that can either be abused by insider traders or other unfaithful employees or pose a risk to existing untrained employees.
internet kiosk expression. That is the answer in most protected environments. And it shouldn't be considered evil against employees productivity. Operational employees (e.g. bank cashiers) should only use a minimum and efficient set of products in order to accomplish their tasks. If they, for their normal operations, require 35+ softwares (like in MPS bank a few years ago) I think their productivity is highly impacted by the number of tools they need to learn. Even if you should not perform non-business tasks during biz hours, there are tablets for those
Commented
Sep 21, 2016 at 10:00
Tor is by-design difficult to block. Yorick's measures will keep the honest employees honest. I would go that route unless HIPAA demands more* Adding detection to the blocking measures means you can identify Tor users and go through management to discipline them. IMHO, forbidding this kind of behaviour should be in the employee's annual certification of business policies and part of your security training program.
If you must rule with an iron fist, blocking everything by default and installing an interception proxy is a common method. This means you will be intercepting, decrypting, inspecting, categorizing and re-encrypting all client TLS traffic. This is common in banks and secure institutions... along with all the privacy implications, deployment complexity and performance issues.
*(I don't know... I haven't done HIPAA)
Since the title refers to detecting such activity I would configure a firewall rule to log but not block connections to known anonymisation services/servers of various types. Obviously this does mean having someone monitoring the firewall logs or some type of flagging system.
There is a slight risk that data may get out but if someone encounters a block they're likely to find other methods/services (which you may not have logging in place for) to get data out of your system.
Allowing a limited amount of data egress gives you targets within your network that allow you to audit their systems access and find out what they're actually doing - such as attempting to access material that's outside of their job scope.
This also gets you around any BYOD issues in environments which permit them as to get to the sensitive data they'd still need their authentication (logins etc.) so you can see what might be at risk.
The downside of this approach is that risks are proportional to how closely the firewalls are being monitored and any flags acted upon so it really depends on the resources available.
