How do you put in controls to prevent a staff using his/her mobile phone to tether 3G/4G connection and download unauthorized files onto the office PC? Of course minimally there must be an AV in place to check for viruses and stuff. But how to stop the tethering in the first place? Any recommendations? thanks
There are potential technical options you can pursue, and several of those have been mentioned in other answers, such as global policies or BIOS settings to disable the USB ports, or physically disabling the USB ports.
My suggestion is that if you have a systemic problem with this sort of thing, it isn't, in fact a technical problem at all, but a policy or people issue instead, and you should be looking for ways to deal with the underlying issue, and not the symptom of mobile tethering.
The most likely cause, is in fact you. (You being inclusive of the IT department, management, and the policies in place.) If your policies are too restrictive, and people are having a hard time doing their jobs because you've removed or disabled the tools that they need, good employees will become frustrated, and they will find ways around your restrictions in order to accomplish their duties. With good employees, productivity always wins the day, no matter how hard you try and prevent it with policy and technology. As the saying goes, security at the expense of usability comes at the expense of security.
So, if that is in fact the issue at play here (and in order to find out you'll have to actually talk to the employees!) then you need to figure out how to change your policies in order to enable them while still effectively managing risk to the business. There will have to be trade-offs, but such is life.
There are other less likely possibilities, such as perhaps this behavior is limited to users who don't know that it isn't allowed, or who would rather goof off at work with things that have no business purpose than do their jobs. If that is the case, it's still a human resource issue, not a technology issue, and the solution is not to crack down on tethering, but to crack down on those employees and educate them or show them the door.
In any case, don't jump straight to a technical solution for a behavioral issue. You likely aren't going to solve the problem, but may in fact make it worse.
The problem with this is the availability of USB ports... if the USB ports no longer work, then they will stop trying it.
I know there are group policies that disallow the use of USB ports through the OS, but I'm not too familiar with if there is a policy that will disable them entirely. If not, then you might be able to either A) disable USB in BIOS or B) glue them shut (effectively ruining the computers, which corporate won't like).
This is where company and security policies can come in handy if you don't want to get all too technical. However if you do not require the need to write to mass storage devices via USB then you can simply edit the registry to only allow for devices to read via USB. Although, if you're staff do need the ability to read/write there are other registry related options but if you're using a group policy; You can use the 'Group Policy Object Editor' to control what a user can and cannot do via USB. including that of preventing the ability to install any device drivers. ... Sorry This is a bit vague, I'm currently at work waiting for a build to finish :)
I guess the policy is there to prevent virus infections because the computers are a Group resource and not a personal resource (eg, employees can take any PC that is available, the employee does not have a assigned "own" PC for the whole employment period).
In this case, I would recommend running some sort of kiosk/readonly solution. One example is booting the PCs over iSCSI with iPXE, where the iSCSI target is read-only. There is a bit complicated setup where you must make the first few megabytes of the read-only partition read-write and then reset this part to original each bootup, else Windows 7 BSoDs at startup.
If you can live with a Linux OS - EXCELLENT then you can host a live distro on a HTTP server and then have iPXE boot them up.
If you want to stick with drives in the computers, then Another solution is to use one of all these HDD protection cards that exist, that ensures a computer is reset to a "pristine state" each reboot.
When you have implemented a read-only/"live" solution, then you can give you employees administrator rights. It wont matter, they can download the worst trojans ever - reboot - trojans gone. If a large trojan infection happens to come, then shut down all work PCs - then start up all PCs again. infection guranteed gone.
If the policy instead is because of sensitive material on the PCs that can be leaked, I would instead recommend moving that sensitive material to "secure terminals", eg hardened PCs where the PC machine is locked into a cabinet, nothing is accessible except screen, keyboard and mouse. And then employees that want to access sensitive materials have to go to a secure terminal. In this case, secure terminals can also physically be locked in and require a access card swipe - where this swipe also unlocks the terminal, for maximum security.
If the PCs are "personal", eg the employee get a own "assigned" PC that is his for the whole employment period, and then that PC is returned or become vacant for the next employee, then I would suggest a policy where "you are responsible for your own PC". Let them do whatever they want, if their PC no longer boot, its their fault. For reformatting you could have a service fee for lets say 50$. When employee leaves, then you reformat PC for the next employee free of charge.
Of course, in ALL these cases, I assume theres user isolation in the network switch activated so PCs cannot "talk" with each other.
Glue the usb connector shut. No BYOD. Put it in writing, and have a workshop.
Alright, ultimately the sensible answer is to provide charging points for everyone at the desk, so noone gets tempted.
And, I'm sure you have a group policy in place that stops you from doing anything right? In linux, you could probably implement this as one of the udev rules.