Great Circle Associates Firewalls
(December 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Cisco's PIX Firewall
From: jeromie @ garrison . com (Jeromie Jackson)
Date: Thu, 5 Dec 96 21:48:25 CST
To: ahuger @ secnet . com
Cc: firewalls @ GreatCircle . COM, Ryan . Russell @ sybase . com

> On Thu, 5 Dec 1996, Jeromie Jackson wrote:
> 
> > 	In reguards to your opinion of the code being more secure because of the
> > widely publicized source code, I would definitely have to DISAGREE with you.

Alfred Huger Wrote:  
> I said no such thing, I stated that it was better to have access to source
> than not to have access to source. And that there was no gaurentee the
> vendor is writing secure code.

 
> > Just because the code is made public does not make it more secure whatsoever
> > Now if you would have said that the code be made public so that a formal 
> > testing methodology be implemented upon it.
> 
> I believe the last line of my message read:
> 
> "This software simply needs to be reviewed on a regular basis"
> 
> And I was not referring to performance tuning........
> 
> 

	I was not referring to performance tuning. If you look @ my statements
they are made in relation to ASSURANCE, not performance.

	Also, you mentioned "This software simply needs to be reviewed on a 
regular basis."

	Simple review of the code doesn't provide much whatsovever.  I believe
it was aparent from my remarks that it is important to have METHODOLOGY within
the testing, not just 'simply...reviewing..'


> > code to the public may give random people a chance of finding a security 
> > problem I would agree.  However, providing code to the public does not
> > provide assurance
> 
> It provides *more* assurance than letting the vendors offer up binaries
> with no outside body to review the source. Ask yourself how many bugs
> come to light from end users flipping through source code, as compared to
> how many bugs the vendors release information on and patch. You will find
> that bugs are most commonly found by the end user, who in *many* cases is
> reading the code and posting the bug to a forum where the vendor cannot
> ignore it (ie: bugtraq etc). 
> 
> 

	I would have to agree with you, that providing the code to the public
gives a better chance of finding problems, since we know vendors don't have 
adequate time to prove assurance.

	I would also submit that if the vendors WERE to implement formal
testing methodologies, that their testing would most likely provide better 
security than that which is found from the public @ large, who is mearly 
glancing @ the code.

	I would also like to comment that I agree with you in the fact that
releasing code to the public is generally going to provide better code.  The
reason for this is not because of the large amount of people reviewing the code,
but because of the lack of adequate testing methods within the vendor community.


	To summarize my comments on the usefulness of the MTA for Cisco and the 
other security vendors.

1.  It would be a good thing for organizations such as Cisco/FW-1 to provide
    an MTA.. The reason I said to 'create' one was mearly so they could 'sell' 
    it as part of their security solution w/o breaking any licensing agreements
     (IE: using SMAP from the FWTK as part of their commercial solution)

2.  Providing code to the community as a whole is not what creates a secure
    MTA agent, it is formal testing methodologies.


Jeromie Jackson
Garrison Technologies
jeromie @
 garrison .
 com

Indexed By Date Previous: Re: Cisco's PIX Firewall
From: Alfred Huger <ahuger @ secnet . com>
Next: Re: .edu w/ firewalls
From: Sameer R Manek <manek @ challenger . atc . fhda . edu>
Indexed By Thread Previous: Re: Cisco's PIX Firewall
From: Matthew Howard <mhoward @ cisco . com>
Next: Re: Cisco's PIX Firewall
From: jeromie @ garrison . com@scet.org.uk (jeromie @ garrison . com)

Google
 
Search Internet Search www.greatcircle.com