Firewall Wizards mailing list archives

RE: Castles and Security (fwd)


From: Antonomasia <ant () notatla demon co uk>
Date: Mon, 8 Jan 2001 21:21:04 GMT

From: "Scott, Richard" <Richard.Scott () BestBuy com>

My sense of things is two fold.  Firstly, if we are to build secure
infrastructures, we need to use quality components.  Would one build a
castle out of straw.  Despite bringing in another analogy, two of the three
pigs built "castles" were not successful!

If I decide to build an infrastructure, I should have the right to chose
adequate components, and if those components are somehow certified, or
legally advertising to be secure, that that should be sufficient.

It may be necessary but there's no way it's sufficient.
There are numerous inventive and incredible ways to make practically
anything insecure.  Honk if you've seen /etc NFS exported rw.

If I build a house and select quality bricks, and find that after the house
was built the bricks were made of baked sand in stead of a concrete mixture
(as advertised) as to allow anyone to enter in to my house, I could have
legal recourse.

While I like the idea to some extent isn't it really going to mean the
customer pays more to cover the added vendor insurance ?   Or are you
really sayng insurance for mistakes should be illegal and vendors should
get it right first time or get sued ?   And how do you split the blame between
MS for IIS displaying CGI scripts (reported today by Guninski) and admins
putting passwords in the CGI's of systems or keeping CC# databases there ?

Furthermore, and this is where the open source community will benefit in the
long term, that components can be analyzed and fixed, whilst products from
the non-open source garage must be fixed by the vendor.

And open-source suppliers will be exempt from the legal recourse you want ?
Or prompt fixes will win immunity ?

                                                         One could analyze
source codes, ascertain a principle idea of security based on how the code
was created.  This is a long winded solution, but hail the new market of
certifying  accounts that will audit products and grant them security
levels.

I can't see this.  Apart from a huge lack of interest from the corporate
purchasers there are frequent headlines about lack of security staff.

Arh, one may say, but we already have security certification, c2 et al.  But
these tend to be used on "government classed" systems, and not singular
components that build the system.

There's a way in which you have to look at the whole system.  Security analysis
should be wider and not narrower than the C2 or whatever state of the machine.
Where is it ?  Who maintains it and backs it up ?  When/How is tripwire run ?

                                   As we concentrate on components entity,
one could include the protocols that are funneled through http.  If a
protocol can be used to by pass security, then it would not be granted a
security license/certification.

If security means "does what I want and nothing else" the definition will
vary from site to site.  And what happens to a product's status after a
new bug report in that product or another that may be used in combination ?

When this highlighted tag actually is seen, I am sure that administrators,
security auditors and alike will be more caring as to actually review the
protocol

I'll believe this when I stop seeing the things I see every day.

--
##############################################################
# Antonomasia   ant () notatla demon co uk                      #
# See http://www.notatla.demon.co.uk/                        #
##############################################################

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards


Current thread: