Firewall best practices

Q: Checkpoint firewall R62 & Nokia IP 560 Hardware based appliance best practices
We have Checkpoint firewall R62 & Nokia I 560 Hardware based appliance , we do audit of rules on quarterly basis but still i feel that lot of tuning to be done on Nokia IP 560 and Checkpoint .Can some one please help me in getting best practices for firewall.

A: Hi ...,
Best practices can be classified in 2 main areas:
1- Information Security
2- Operational

For information security, make sure that you follow a higher level information security framework with integrated risk management. Firewalls must be a part of the bigger picture, not standalone devices.
ISO 27001, NIST, COBIT or FFIEC can be a good start.
There are several guidelines by FFIEC if you are operating at financial services industry.
http://www.ffiec.gov/ffiecinfobase/html_pages/it_01.html

You can also check firewall specific guidelines from NIST
http://csrc.nist.gov/publications/nistpubs/800-41/sp800-41.pdf

Once you make sure that you address governance, risk and compliance (GRC) related concerns you can dive into operational issues such as reliability, high availability, performance, scalability, manageability.

We have been managing thousands of Check Point systems under Nokia platform. It is difficult to cover best practices in single post (from change management to patching, from backup policy to cluster optimization) There are several good recommendations in other posts as well; here is a quick view from my side.

1- Optimize rulebase (most used rules at the top, use logging intelligently, avoid duplicate objects, check unused objects rules, make sure that overlaps do no exist, use network object, decrease NAT usage etc)
2- Upgrade to R65 for Check Point. It is more stable and you will get all the new fixes faster.(when compared with R62)
3- IPSO 4.2 will bring you more features with SecureXL, QOS etc. but go over the release notes carefully. Make sure that SecureXL is enabled within the current deployment.
4- If you have performance issues and you are not planning to upgrade platform check the new ADP cards from Nokia.
5- Architecture-wise avoid running non-firewall features such as SmartCenter, AV, filtering on your Nokia unless you need them.
6- If you have site-to-site VPNs check the route based VPN feature with dynamic routing for better redundancy

I also recommend using 3rd party test services which include DDOS.

For automation, you can use firewall audit, change management tools such as Tufin, Algosec and Firemon (we work with Tufin). These tools will give you a lot of input on audit. On the security risk management side if you have budget, you can check SkyboxSecurity and RedSeal. They will be really helpful.

If you have any specific questions please let me know,

cheers,
- yinal

ThinClient Security

Q: Kindly elaborate your experience with ThinClient security from the likes of HP and Wyse.

Currently researching the following with regard to Thin Client Security :

1. Need of an AV in ThinClient and its manageability.If an AV is required which ones recommended and why(file size,footprint on the OS and detection capability)
2. How to enforce security policies in Embedded XP. Eg : Device control/lockdown of the system etc
3. Case study of ThinClient security - breaches that has happened in the past;best practices and recommendations etc etc
4.Possibility of a ThinClient turning on to be a zombie for a botnet and any other security considerations to keep in mind


A: Hi ........,
It is difficult have a generic answer for all thin clients since there are several OS flavors and several different deployment/use cases. HP offers clients with Windows CE, NeoLinux , Windows XP Embedded, Debian Linux 4.0 ,HP Thin Connect and Wyse offers clients with Wyse ThinOS ,Windows XP Embedded, Wyse Linux Windows CE etc) …You can choose to restrict user activity to minimum and reboot with a fresh image each time, or you may choose to customize your thin OS with some execution and allow limited apps in addition to RDP, ICA type terminal clients. So your risk profiles vary based on your decisions.

That being said here are my comments


Need of an AV in ThinClient and its manageability. If an AV is required which ones recommended and why(file size, footprint on the OS and detection capability)

If you are looking at XP embedded (XPe) as you stated down below you have some options. CA Anti-virus (formerly eTrust) is the first player with a small footprint.. Symantec offers full endpoint security with The Symantec Endpoint Protection for Windows XP Embedded. disk/cpu/memory requirements on Symantec client is 30Mb/1.3Ghz/128MB.. You can also use McAfee VirusScan Enterprise on XPe. I would crosscheck the licensing options on each of the option as well.. If you choose terminal connections and lock down the client only you may question the necessity as well.


How to enforce security policies in Embedded XP. Eg : Device control/lockdown of the system etc

Like in real XP, group policies and windows firewall. On Windows XP Embedded with SP2 you/your vendor can configure your run-time image for better security. Windows XP Embedded run-time image should include Group Policy Client Core Gptext.dll and Windows Firewall components.You can use MMC to update Group Policy on a deployed run-time image. You can also add Symantec endpoint security to the mix..

Case study of ThinClient security - breaches that has happened in the past;best practices and recommendations etc


Breaches seldom make it all the way to case studies for a good reason. In the past I have not personally witnessed a “thin client” related breach. But XP embedded is very close to XP and it is subject to similar attacks and even worse since it is not a closely monitored OS. There is a higher risk on thicker Linux and XPe distros if the end user is allowed to make any changes in the configuration. Best practice is to control all environment and disable user level access to OS settings completely. Remote exploits ( e.g. JavaScript, ActiveX vulnerabilities) will be sand-boxed if the user rights a restricted properly. I personally like terminal connection only or OS streaming models where every boot is a fresh start.


Possibility of a ThinClient turning on to be a zombie for a botnet and any other security considerations to keep in mind

It is technically possible if user has a right to modify anything and execute the changes. I would choose the thinnest model if the requirements do fit.

cheers,
- yinal

How to allow Internet access for research and protect servers at the same

Q: How do we allow Internet access for research and protect our servers at the same time? As a programmer analyst I use the Internet to do research for my work. We are looking for a way to still allow this but protect our servers where client info is held. We don't want to be constantly updating a trusted sites list with website addresses that our programmers use. Any suggestions would be greatly appreciated!

A: Hi ....,
As recommended in the previous posts, the first action is to follow a comprehensive security framework to make sure that all high level security concerns are addressed with appropriate security controls and information security governance is in place. (You can choose NIST, COBIT, ISO 27001 etc)

When the policies and procedures are addressed, on the architecture side I have several recommendations:
1- Segment your servers from research desktops. Servers have to be behind security controls like intrusion prevention, firewall, data leakage protection, database security, behavioral anomaly detection etc.
2- Secure your desktops and servers with client based firewalls, host based intrusion prevention systems, 802.1x, anti-virus, anti-malware, encryption, group policies, tripwire, application control, secure IM etc. Always secure your client data, use rights management tools, database security tools, encryption tools and audit tools on your servers where you keep client data, make sure that every security policy is enforced. Strong authentication is also recommended. Make sure that you control every output device like USB tokens, CD writers, backup tapes etc.
3- Filter your internet http/https access with anti-malware, anti-virus, instant message protection in addition to URL filtering, you can use a web based filtering service like ScanSafe or you can go with an in-house solution like BlueCoat, Websense, SecureComputing etc type of URL + AV + IM filters.. Deny outbound tunnels on external gateways. (which is a very common way for programmers to bypass filters…)
4- And for your programmers… Managing white-lists (trusted sites) is painful. Use a self-service management gateway for your URL filtering so that the users can request the sites that they want to access for limited time, and the approval process is automated. The way it works is to have a web portal where end users request for new trusted sites for research. Approval can be automatic or manual, unlimited or limited, user restricted or for all. You can integrate this portal with your internal user directory such as active directory or LDAP, so that portal can recognize each requestor without additional login

Let me know if you have any specific question about the any of the solution areas that I have briefly mentioned.
cheers,
- yinal

Type rest of the post here