|brent timothy saner on 4 Aug 2017 13:34:01 -0700|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: [PLUG] Firewall/security philosophy [was: SSH Hardening : Request for Best Practices]|
On 08/04/2017 02:26 PM, email@example.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.
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