From owner-freebsd-security Sun Apr 8 2:26: 1 2001 Delivered-To: freebsd-security@freebsd.org Received: from cpimssmtpoa04.msn.com (cpimssmtpoa04.msn.com [207.46.181.114]) by hub.freebsd.org (Postfix) with ESMTP id 263DB37B422 for ; Sun, 8 Apr 2001 02:25:58 -0700 (PDT) (envelope-from JHowie@msn.com) Received: from cpimssmtpu13.email.msn.com ([207.46.181.88]) by cpimssmtpoa04.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Sun, 8 Apr 2001 02:25:57 -0700 Received: from x86w2kw1 ([216.103.48.12]) by cpimssmtpu13.email.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Sun, 8 Apr 2001 02:25:57 -0700 Message-ID: <05f601c0c00e$8331fba0$0101a8c0@development.local> From: "John Howie" To: "jal" , References: <200104071610.RAA18117@mailgate.kechara.net> <3ACF83FA.55761A7B@globalstar.com> <20010407162552.D87286@hamlet.nectar.com> <058701c0bfad$265e8530$0101a8c0@development.local> <20010407173910.B69155@spawn.nectar.com> <05aa01c0bfb4$ec3a0de0$0101a8c0@development.local> <20010407180040.B87468@hamlet.nectar.com> <05b901c0bfb8$d79a1160$0101a8c0@development.local> <20010408005844.A2857@lorenza.abulafia.com> Subject: Re: Theory Question Date: Sun, 8 Apr 2001 02:30:11 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 08 Apr 2001 09:25:57.0780 (UTC) FILETIME=[EB198540:01C0C00D] Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org jal, You hit the nail on the head. You mitigate the risks you can, and insure against the rest. john... ----- Original Message ----- From: "jal" To: Sent: Sunday, April 08, 2001 12:58 AM Subject: Re: Theory Question > On Sat, Apr 07, 2001 at 04:16:55PM -0700, John Howie wrote: > > > > [...] If I force would-be > > intruders to have to defeat/circumvent individual measures such as > > firewalls/NAT boxes just to determine my topologies before they can even > > make an attempt at an attack on servers, then most will give up and go away. > > Without (dis)agreeing with John or anyone else, I feel like > this is the time to point out that security is a cost, to > be evaluated like any other. At a certain point, the average > business needs to ask itself whether paranoia[1] makes any sense > in spent resources, compared with the measures taken to secure > weaker links, not to mention the cost of losing whatever is being > protected in the first place. > > So you have the most kick ass network of IDS boxes watching your > heirarchical firewalls, and have deployed the right protocols, > LLE, etc. in all the right places. How's your phone system? > How hard is it to trick someone's assistant, or the Extremely > Important Person themself? What does it mean if that works? If you > reply that that isn't a techincal problem, you don't get security, > which is only ever approaches being half technical in nature. > > WRT the original problem, my suggestion is to ideally treat the IDS > as an island, cut the TX pair, assume it can be flooded/compromised, > and write logs in a way that makes it difficult to alter them without > being noticed. If the box has to transmit data, you begin making > different trade-offs involving the network security of your security > network. Look at those closely, but keep an eye on the value > of what you're protecting. In general, I'd say that if you have > legitimate reason to be paranoid enough to build this sort of thing, you > have legitimate reason to not trust private networks, etc. to hide > you. Again, policy matters a lot - did some random admin leave a > laptop connected to the "secure" network when they ran off to fix some > email problem? If you worry about things on this level, the network > structure is not your biggest problem. > > -j > > [1] Intel "only the paranoid survive" Corp. was given a nice > demonstration of internal security issues by Randall Schwartz. > Leaving aside your view of what he did, it makes a nice object > lesson on the limitations of a mostly technical (followed by > legal, unfortunately) approach to security problems, some of which > they apparently didn't know they had. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message