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

[bergman@merctech.com]

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 

=> 
=> ---rsk
___________________________________________________________________________
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