Video Screencast Help
Give us your opinion and win with Symantec! Please help us by taking this survey to tell us about your experience with Symantec Connect, so that we can continue to grow and improve.  Take the survey.

Balancing usability and security- Firewall discussion

Created: 05 Jun 2013 | 6 comments
Car_Bed's picture

The topic and or point of this thread is to ask the engineers, and customers, the best fit for satisfying the end users ability to get more done in less time, and the ability to protect a system.

The main topic I’m concerned with is the firewall, with AV it can be scaled and tuned to fit the specific needs (Locations for developers where SONAR or Legacy True scan is peeled back a bit), you can use 3rd party products to manage application and device control, and use mostly out of the box IPS policies (Unless you have copious amounts of spare time to do nothing but write custom IPS signatures. My main focus for this thread is the Firewall, and the best balance to use.

I would envision separate policies, so while inside my perimeter that’s a given and well protected, however outside is the one in question. If you say "prompt for access" it at times, and in many cases, causes a plethora of notices for end users. If the point is to make Symantec NOT STINK (Sorry Symantec, just how I feel at the given moment, hopefully you can build my trust back), then having constant pop-up seems like a good way to control things from a security perspective, but can potentially irritate the end user. So this leads to my question, what are you doing?

What do other high license count engineers do, i.e. 5K+ SEP Clients or more. If you want to NOT leave a bad taste in someone’s mouth from a deployment, are you using some magic with your firewall, not using it at all, etc..

Welcome any feedback, and appreciate it in advance
 

Operating Systems:

Comments 6 CommentsJump to latest comment

Brɨan's picture

Because we have other security layers in place for our internal network, our ON NETWORK firewall policy is a little more laid back. My main focus is on user's who are mobile. The usual suspects are allowed (80, 443, vpn port) but other than that, the users are pretty limited in terms of port availability. We also have some rules in place which are set to Allow but written to the Traffic log so they can be analysed for malicious activity. All browser activity is monitored and analysed as well. If users are truly in a pinch, they call the helpdesk and open a ticket, from there I work with them to get logs for analysis and make a rule adjustment if deemed necessary. I'll send them the updated policy to import and away they go.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Car_Bed's picture

What I’m thinking is allow any outbound, and "Ask" for inbound. Yes malware can phone home, but my theory is that if I leverage A) Download Insight and B) “ASK” for inbound but log this, the malware had to have gotten either past our other "Pieces" of protection while inside, already there, or  the end user said YES (to download Insight) to a given file specimen while they were outside the network. This can be also handled on a case by case basis

what are your thoughts on this approach?

My thinking here is balance usability and keep my eye on things, without putting time sucks into constant policy adjustments (Not saying this in a negative way, just tough in our environment to constantly have to monitor this and add adjustments on the fly)..

Let me know your thoughts.

Thanks for the feedback
 

Brɨan's picture

Any time you can increase your security posture, you're in a better situation. What you're doing or wanting to do is better than the default firewall ruleset so you're on the right track. Do you have a good feel for what your users are allowed to do while off network? If so, you can build a firewall policy around that. I would probably first start out by setting the rule to allow and log before setting to "Ask" but it depends on how savvy your users are as well. If they continuously get hammered with popups do they know how to respond? I'm in an environments where monitoring is a large focus but I realise not everyone has that luxury,

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Car_Bed's picture

Im with you, and yes, we have an entire group that just looks at traffic, patterns, 24/7..

So perhaps at long as its logged, the fewer the prompts, the better..

I think I might go the inbound "ASK" route and see what happens for a 1st round of deployments to the test "gang"

Whats your recomendation on setting a rule to do this, I.e ASK for any inbound..

It seems as though Source / Destination doesnt allow a * wildcard to say Anything inbound ASK for access, but Outbound allow.

Thoughts...

again, thank you sir

Brɨan's picture

As long as your test group is aware of what's to come and you have the necessary backing of mgmt than I don't see any harm in implementing it. I wouldn't do Ask on outbound as user's won't get any work done except clicking on pop ups all day.

Inbound could still be a struggle if you do for all traffic. Are you planning to just monitor certain apps/ports/services?

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Car_Bed's picture

outbound is going to be log, thats it as the user would get flooded with rules. Initially i was going to have a standard build, and almost whitelist the standard set of apps on the FW side for traffic I "Want" to call out in a explicity allowed rule. for inbound I was thinking of doing prompts for items such as RDP