Re: [PLUG] Firewall/security philosophy [was: SSH Hardening : Request for Best Practices]

[brent timothy saner <brent.saner@gmail.com>]

On 08/04/2017 02:26 PM, bergman@merctech.com wrote:
> In the message dated: Fri, 04 Aug 2017 09:34:37 -0400,
> The pithy ruminations from Rich Kulawiec on 
> <Re: [PLUG] Firewall/security philosophy [was: SSH Hardening : Request for Best Practices]> were:
> => On Wed, Aug 02, 2017 at 01:05:33PM -0400, Rich Freeman wrote:
> => > What is the best way to go about this?  I assume you're talking about
> => > blocking outgoing traffic by default, since everybody already blocks
> => > incoming traffic by default.  It seems like you could spend a LOT of
> => > time playing whack-a-mole with firewall rules punching holes for
> => > legitimate traffic that way.
> => 
> => Not just blocking outgoing traffic by default -- which everyone should
> => have been doing for the last 15 years -- but only enabling traffic in
> => either direction based on port, protocol, origination host, origination
> => network, origination country, destination host, destination network,
> => destination country, volume, frequency, etc.: any and all criteria.
> 
> Sure, if you can enumerate those rules, in sufficient detail and accuracy,
> and be responsive to changes. There will be changes in what should
> be permitted for the business need. 
> 
> Security policies have very different meanings in different environments,
> but it sounds like you're making sweeping statements about policies that
> should be enabled by 'everyone'.
> 
> => 
> => Yeah, that's a lot to ask, but every one of those things cuts down
> => on the attack surface -- which means when an exploit emerges it will
> => be much harder for someone to use it.  And since we know, a priori,
> => that exploits *are* coming, it's better to pre-emptively block them
> => rather than frantically try to patch when they arrive.
> 
> Absolutely.
> 
> => 
> => I suppose there are two things that become clear from that: the first is
> => that one size does not fit all.  The way you approach this for a server
> => farm is different from the way you approach it on a desktop.  The second
> => is that it requires that you know EXACTLY what network traffic you need,
> => why you need it, when you need it, where it's going, how much of it
> => there should be, etc.
> => 
> => Some folks say that the latter is hard or even impossible.  And that's
> => when I quote Ranum -- from that same rant:
> => 
> => 	"How can you call yourself a 'Chief Technology Officer' if you
> => 	have no idea what your technology is doing?"
> 
> That's a nice sound-bite, a slogan, a goal.
> 
> That is not a operational plan.
> 
> And, you didn't quote his next sentence:
> 
> 	A CTO isn't going to know detail about every application on
> 	the network, but if you haven't got a vague idea what's going
> 	on it's impossible to do [...] virtually any of the things in a
> 	CTO's charter.
> 
> That directly contradicts your assertation that "it requires that you
> know EXACTLY what network traffic you need, why you need it, when you
> need it, where it's going, how much of it there should be, etc." Sure,
> that degree of enumerating goodness may be possible in some environments,
> such as on a dedicated application server with no user processes, but
> not in every real-world environment.
> 
> 
> Your statement that one size does not fit all is exactly correct.
> 
> 
> Having "an idea what your technology is doing" may lead to a security
> philosophy that is very different than what you are advocating. Try
> to remember that each element -- the security stance, the inbound
> and outbound network traffic, the applications, should be designed to
> support human beings with tasks they need to accomplish for the business,
> not designed to meet some abstract philosophy about computer security,
> no matter how well intentioned.
> 
> Certainly, computer security is necessary to keep the machines available,
> and may sometimes be intrusive, but the bottom line is that computers
> should be tools to enable people to do things. The implementation of any
> security stance must balance the need to keep machines functional and
> data safe with the need to allow people to use those machines and data.
> 
> In practical terms, maybe that means there's minimal outbound filtering
> (ie., blocking known-malicious sites, not a default 'deny' stance),
> or other policies that don't follow your recommendation.
> 
> Mark 
> 

Further, I'd argue a NIDS/NIPS system does, on a holistic level, the job
better and with way less human overhead most of the time; perhaps with a
caching proxy that will analyze web traffic dropped in as well... (This
is, of course, also debatable and certainly is not a one-size-fits-all.)

Either way, proposing a default-deny/default-drop for all outgoing
traffic for all networks, no questions asked, as the "best" policy is
madness. I'd like to think we've moved past that as a species and have
developed more elegant and robust approaches.

Attachment: signature.asc
Description: OpenPGP digital signature

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug