Re: Isolating internal servers behind firewalls

[D Sharp <drsharp () pacbell net>]

Behm, Jeffrey L. wrote:

> On Tue 9/11/2007 12:11 PM,  D Sharp said:
> Summary:
>
>  
>
> > Can segmenting/filtering network level provide a greater level of risk reduction?
> >    
>
>  
>
> >         If you don't review every port request for risk, and deny 
> > those that are risky, then you are just tracking the traffic good/bad.
> >    
>
> Although "risky" is a relative, and not a universally defined, term, the question remains: "Is Windows file sharing 
> risky?" 
>  
Exactly so: "Risky" is the relative term that the organization needs to 
understand and quantify.
Sorry, but I thought we were addressing more than just the risk of 
"Windows file shares".
    It needs to be part of the analysis of the applications and enviornment.
Examples:
    Does every desktop require access to every server's file share port, 
in a non-filtered enviornment?
    If there is one or many SQLservers, does every desktop need open 
access to this port, or is it just other servers? And likely DBAs.
    If you have a/or several intranet IIS servers, (and all the web 
pages are http), do desktops really need access to the file share ports?

Or take my earlier example: virus attack via AV server port.
    Should I leave the AV port open between all my desktops on every 
server, or just the AV servers?

> 1) If one thinks Windows file sharing is risky, then that traffic to the protected servers must be denied. If it is 
> denied, then why have Windows file servers?
> 2) If one thinks Windows file sharing is not risky, then I have no basis to argue the point any further.
>
> I suppose you could prevent meltdown by blocking everything that is risky, but then you have a network that doesn't 
> function, either.
>
>
> I used to think that segmenting/filtering *could* provide a greater level of risk reduction. In a perfect environment, 
> it could. However, in the real world, where $$$ talk, I don't believe that is the case(maybe I'm already becoming too 
> crusty at age 42?). Environments are sometimes very dynamic, and maintenance of the environment gets pushed down to 
> the low man/woman on the totem pole, because the senior folks are too busy fighting the fire du' jour, or designing 
> the next big thing, and don't have time to mess with such mundane tasks as maintenance of rules. Those (less expensive 
> folks) left to do the maintenance typically have less experience, and are more apt to make a human error when 
> implementing the filtering rules. One typo that goes unchecked (because checking it costs even more $$$), and the 
> firewall is wide open.
>
>  
I agree with you about the push down to the lowest sentient being used 
to type in firewall rules. But I don't agree with giving up.
But that likely has more to do with were I currently work, and the 
information at risk.

If the risk is that a 'typo that goes unchecked [because of cost] and 
the firewall is wide open' speaks more to a faulty risk analysis, and/or 
audit function. But if management has signed off on the known risk of 
loss, by not implementing appropriate processes, then yes a wide open 
internal network is the accepted risk.

We try and put internal rules into a template form, that a security 
person interviews the developer/adminstrator for the required ports.
The template has 'default ports' for Windows and Unix servers, which we 
find a useful way to mitigate implementation/typos.
We do have pier reviews for production firewall changes.

Speaking of costs, and speed. Our operations teams (networking, server 
admins, storage) are working on bringing in tools to automate their 
processes. What once was known as provisioning is now "virtualization 
automation". This is likely another discussion topic, but does anyone 
have suggestions around this?

> Jeff (no personal attacks were implied - hopefully it comes across that way)
>  
>
>  
None seen. The issues need to dealt with, one way or another. Just hope 
this helps others skip the pain recorded here and implement better 
solutions.

Thank you,
Duncan

> ------------------------------------------------------------------------
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () listserv icsalabs com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>  

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards