Re: Re: [Security] Newest Symantic Security Software

Ryan L. Means wrote:

> On 5/10/2005 7:50 AM, Tom Holub wrote:
>
>> On Tue, May 10, 2005 at 12:36:49AM -0700, Ryan L. Means wrote:
>>
>>> However, when CISC talked about allowing SNS to scan through
>>> host-based firewalls, I believe that we did weigh the risks.
>>> There were people on both sides of the issue, but maybe the right
>>> arguments weren't made. The standards are designed to be
>>> flexible...
>>
>>
>>
>> As far as I recall, CISC didn't decide to require holes for SNS's
>> scanning.
>>
>

> Tom,
>
> CISC did approve changes to the implementation guide that required
> holes for the SNS scanners as part of a "correct configuration". Note
> that the language of the standard specifies that the firewall
> configuration must be configured according to the implementing
> guidelines. My revision of this page has not been posted to the SNS
> site yet, but these changes were approved 4-5 months ago. However, I
> assume that we'll be discussing this at our next meeting anyway, so
> maybe it won't make it up there at all.

Ryan:

As I mentioned to you today, I think this should be a "strong
recommendation" and not a requirement of policy. The discussion here
seems to show that there is not consensus that this is appropriate or
that it even provides the best security. It may be that with certain
workstation OSes, the ability exists to determine the overall patchlevel
of the machine by scanning certain network-listening services; and that
the overall patchlevel can reveal information about vulnerabilities that
don't require a network-listening port. But I know for a fact that this
simply isn't true with all OSes and all types of networked devices.
Such a policy would also be unenforceable.

We have all discussed how understaffed, underfunded, and overworked we
all are. It is therefore necessary to prioritize work, and security
work should be a high priority. Minimum Standards does an excellent job
of this because it provides mechanisms for preventing and combating the
most likely attacks. If allowing SNS scanners through *host* firewalls
is given the force of policy, then it is elevated to the same priority
as physical security, patching, encrypted authentication, and even
having a host firewall in the first place. That just seems
counterintuitive to me, as does the notion that you are required to put
a host firewall on your machine and that you are also required to weaken
it. I have seen how people are grappling with the letter of the policy
and not always catching the spirit of the policy. By making the letter
more complicated, we potentially undermine the spirit. (I will admit to
some guilt here, as some of my past suggestions have made the policy
more complex, but I hope it has also become clearer.)

I am concerned about risk, but not in the same way that Charles is. I
agree with ken that there is a low risk of spoofing. What concerns me
is that as firewall rules become more complex, the chance that a syntax
error will creep in, possibly exposing the system to malice, is greater.
  I agree that this risk is outweighed by the risk posed by hardware
firewalls that block SNS scanners from entire subnets. There are so
many vectors for compromise in that scenario that SNS really needs
visibility. (However, they still won't get it behind every firewall no
matter what--NAT is an example.) But while I can see allowing SNS
scanners behind hardware multi-host firewalls, I do not believe that the
risk of compromise from being invisible to SNS scanners outweighs the
issues that have been raised here when it comes to host-based firewalls,
at least not for all types of systems.

We're all working very hard to make Minimum Standards work. It's really
impressive how everyone is taking these policies seriously and working
in good faith to make all of our systems compliant. It's important to
get input from everyone on what's working and what's not, and I am happy
that we have a forum for constructive discussion like this.

michael

------------------------------------------------------------------------
The following was automatically added to this message by the list server:

For information about Micronet, including subscribing to
or unsubscribing from its mailing list and finding out
about upcoming meetings, please visit the Micronet Web site:
<http://micronet.berkeley.edu/>.
Received on Tue May 10 14:43:46 2005