This is a discussion on Re: [fw-wiz] Isolating internal servers behind firewalls - Firewalls ; 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 ...
Behm, Jeffrey L. wrote:
>On Tue 9/11/2007 12:11 PM, D Sharp said:
>>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.
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
>firewall-wizards mailing list
firewall-wizards mailing list