Friday, December 21, 2007

How to separate critical application network from network connected to the Internet within a company?

Q: How to separate critical application network from network connected to the Internet within a company?
In many companies users have to access to the Internet and also to some corporate application from the same computer. But in some cases these applications are very critical so we can't accept the fact that a computer can connect to the Internet and to the critical network in the same time, in fact this computer can be a gateway for the threats coming from the Internet to the internal network (Trojan horse, virus, intruder, ...) that's why we think about the separation. The best separation is the physical one, but here we face a problem of duplication (Cable, Computer, NIC) and users can't easily accept .
Is there solutions for this problem, and how to separate networks in the same company with less cost and if we choose the physical separation, what's the best way to do it?

For example, in a bank network, users connect to the bank critical application throw their computers, and we want to provide for them an Internet connection from the same computers without taking risk.
How we can implement a secure solution?

Regards
…..

A: Hi ….,
As you have stated it is close to impossible to guarantee that a client that is connected to Internet is 100% secure.
Here are the basic action list that we see in high risk environments:
1- Make sure that the servers are in a different segment, where access to local servers are regulated with strong security controls, start with firewalls/ACLs and you may deploy all the way up.. IPS, Anomaly detection, content control, stronger auditing, strong auth etc. Most of the banks are deploying internal server segments at the moment.
2- If segmentation is not enough, you can virtualize server access such as terminal access, SSL-VPN , citrix etc. So that server environment is different than client environment. Split tunneling from internet surfing clients to critical servers get really difficult with terminal access.
3- Another option is to virtualize clients so that you can use another client when connecting to high risk servers. This is still difficult. But this option makes split tunneling difficult

After segmentation (when it is not enough), we usually recommend SSL VPN type of control since SSL VPN intermediates all requests, so the end user is never in direct contact with the server resource. We can enforce application-layer visibility, granular authorization to the URL, file, and server level.. SSL VPN solutions usually offer detailed auditing records including user, application, resource, time and event details . You can add factored authentication so that malicious applications cannot reach the server environment without the physical factor (such as tokens)

Another interesting solution is from Blue Coat, I have not personally tried it but the their RA client encrypts all information stored by the browser, including cache, temp files and cookies, and clear all session information at the end of SSL VPN session using DoD 5220.22-spec file deletion Their pre-authentication and continuous spyware scan that leverages AMP (Adaptive Malware Protection) technology may provide a pre-login scan for framegrabbers and keyloggers and continues to scan for duration of user session Configurable split tunneling to block or enforce split tunneling is a good feature.

I can give you more insight about the high-low-medium cost options if you need.
Let me know if you have any questions,
Regards,
- yinal

No comments: