
It's a fine line. You need to make sure that next big virus doesn't bring down your network, and at the same time, you need to make sure you aren't preventing new orders from coming in the front door of your company network.
There are a lot of new tools out there to help mitigate threats, including anti-virus, anti-spam, anti-phishing, intrusion prevention, intrusion detection, and others.
There's even tools to help ensure employees are being productive instead of surfing the web and possibly bringing in viruses; these include URL filters, web page blocking, policy managers, etc.
The biggest problem with all these solutions is determining when enough is enough and when there's too much security in place. “Too much” security impedes business.
I remember my previous company where we had a great anti-spam product in place, but we always had to turn it off the last week in the quarter to make sure we didn't falsely tag any last minute orders as spam, and prevent us from making our numbers for that quarter.
The employees suffered through with more spam for one week, and the company got to make sure it recognised all the revenue it could that quarter.
So what's the right answer to the security dilemma?
The right level of security for each organisation will vary depending on your enterprise, your business processes, and your specific needs around policy and acceptable use.
Regardless, as the administrator, you need to know when something happens on your network, what or who caused it, and then make sure you can prevent it from happening again.
At a bare minimum we know we want to block all known viruses and malware, and depending on your corporate policy, websites that reduce your productivity (shopping, adult, news, etc. sites).
We want to let our employees know there's a good "acceptable" use policy with regard to accessing the Internet from the office.
Once you’ve decided what your policy is for your employees you need to make sure you have a way to distribute knowledge about the policy (to make sure everyone knows what the policy is); next, enforce the policy; and finally audit the policy to make sure it is working.
Letting everyone know about policy is no simple task. Just posting a policy does not guarantee everyone will see the policy.
A general use policy splash page the first time an employee accesses the web is probably the safest solution, and then you can provide regular reports on employees who have seen and agreed to the policy.
It guarantees the user has seen the policy and they must click an agreement link to the policy to surf the web.
The hard part about creating an acceptable use page, is the need to implement and require authentication by end-users to use the web. This is an absolute requirement, because without it, establishing accountability and the ability to do forensics after security events is much harder or even impossible in some cases.
Integration with your existing authentication system is ideal, and provides the least hassle for your end-users when managing passwords and userids.
The other important part of implementing policy (in addition to authentication), is of course policy enforcement. Policy enforcement must be flexible enough to allow for exceptions (does the CEO get full web access, while other employees get limited access to approved sites), yet complete enough to cover any scenario your policy requires (e.g. allowing full access during the lunch hour and after hours, but block certain sites during work hours).
There may be other policies you may want to implement as well, including allowing or denying instant messaging, and even if you allow instant messaging, you may want to deny file transfers across instant messaging.
Other examples include allowing certain types of sites (e.g., travel or social networking), but disallowing certain types of content (e.g., executable content or images on those sites). Each organisation will have their own policy, and it’s important to determine and implement the one that fits your organisation.
The security device you choose to implement your security should flexible enough to work with your installed authentication mechanisms, be able to display an acceptable use policy splash page on first usage, be flexible and complete enough to implement your policy, and finally have extensive logging and reporting (so you have complete accountability).
Timothy Chiu, director of technical product marketing at Blue Coat.