-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> -----Original Message-----
> From: Bennett Todd [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 26, 1999 9:42 AM
> To: Frank Knobbe
> Cc: Firewall List
> Subject: Re: Netmeeting
>
> I don't know about the person you are replying to, but at
> least for me, there
> are plenty of clients who just _adore_ that attitude, and
> those who don't
> appreciate it, I wouldn't want to work for. I'm (among other
> roles:-) a
> security admin; I do _Not_ want computers under my charge to
> be burgled.
Neither do I. I'm not saying that we all should live more on the risky
side. I just can not stand the attitude that states 'if there is the
slightest flaw, I won't use it. Period.' Even if there is a flaw, you
may be able to eliminate that flaw by the way you implement the
product.
> > A lot of times the best security consultant is the one that
> implements the
> > fewest security constraints while still providing
> sufficient protection for
> > information and systems.
>
> That trailing clause "while still providing sufficient
> protection" quite
> undermines the first bit "implements the fewest [...] constraints".
Oh, not at all. 'The fewest constraints' means the amount of
constraints necessary to ensure security of information, individuals
and assets. A simple photo-ID batch may be the least restraining
countermeasure, and completely sufficient for a bank, whereas the
rectal...uhm...retina scan or DNA analysis is more secure, but not
required.
> - Applications get worse and worse. Users want to run things
> like Netscape.
> Users that really want to avoid getting useful work done
> sometimes even
> want to run OSes like Windows. Security is _rapidly_
> coming unglued on
> client machines.
Don't expect me to comment on this nonsense.
> - People are falling all over themselves to invent new
> protocols --- and
> increasingly, tunneling those new protocols through old
> ones in an effort
> to bypass any attempt at security controls. By and large
> the new protocols
> are being designed without attention to security issues.
Actually you would tunnel older protocols through newer ones...I'm
sure that is what you mean. But if these new protocols eliminate the
security issues, then please explain, why we shouldn't?
> - The population of burglars is increasing by exponential
> leaps and bounds.
> Exploits that used to never get written, for "purely theoretical"
> weaknesses, are now appearing regularly.
Correct, and the population of cyber criminal as well ;)
Also, the new kidz on the block sometimes come up with very weird and
novel exploits. Can you say nmap?
> - Legal remedies remain for the most part impractical.
> You'll have a hard
> time finding the perp at all. You'll have a _much_ harder
> time doing so in
> a fashion that builds and preserves a chain of evidence
> sufficient to get
> an indictment. You stand very little chance of getting the
> person arrested
> and tried.
Actually, that continues to be a head-on-head race between the
perpetrator and the investigator/law enforcer. Finding the perp does
get a little harder, because a) the jungle out there gets bigger, and
b) See nmap and the like...
The forensic part did not change much, except that new tools are
available to ease the gathering of evidence. Getting an intruder
arrested is of course hard, but sometimes I find it harder to convince
the victim to pursue and press charges. If we don't fight back and
kick hacker-butt, then the war is lost.
> - You don't have an infinite budget of either time or money.
With the proper procedures, tricks and innovations, you will be able
to succeed. After all, a lot of inventions were born out of
desperation...
> The only way to even get by is to draw a very very hard line, set an
> exceedingly strict security stance, educate your users about
> the nature of the
> problems that you are fighting, and the threats to the
> organization, and find
> ways to work around the occasional legitimate need that
> initially seems to
> argue for tearing down your security barriers.
With a different approach and a different strategy, you may find it
easier, cheaper and more productive to still provide security. As a
security admin you need to stay very flexible. It is possible that you
need to toss the complete security concept of your network from one
week to the next, just to allow the implementation of a single
additional requirement (and I don't mean spending tons of money
again).
> I don't know about the person you were replying to, but no, I
> don't suggest
> filtering and disallowing that kind of stuff, I filter
> _Everything_, and only
> _allow_ select, carefully-chosen protocols, and these
> playthings never even
> get considered as candidates for opening up. To even start
> considering a new
> protocol, there's gotta be a strong business case for that
> protocol.
Let's say the whole board of directors wants NetMeeting... strong
enough case?
> Then
> the protocol has to have a clear security model (which,
> incidentally, SMTP
> definitely _has_), and on examination we need to be able to
positively
> eliminate any threat that an unknown, independant outsider can use
the
> protocol to violate our systems. Further, if even select,
> identified, chosen
> outsiders could possibly do anything wrong, the protocol has
> to ensure that
> they can be positively identified and authenticated, and we
> have to restrict
> the config so only people with a strong contractual legal
> reason to do us no
> harm are gonna be allowed at it.
Alright, now we have almost the right attitude. I would replace
'protocol' with 'implementation'. Apparently firewall admins only
focus on protocols. That is wrong. You need to open your mind set to
the requirements and their implementation. Most of the time you deal
with protocols, but a lot of times you also deal with _position_ or
_placement_ or even helper apps.
Yes, you can work with an un-secure protocol, in the DMZ for example.
Agreed, you should not it _between_ the DMZ and the internal net, but
you may choose to allow it again only in the internal net.
> No, you've got it backwards, if your stance is that any
> cutesie toy that comes
> down the road must be allowed through if any user says they
> think they might
> want it, then you might as well disconnect the firewall and
> run a piece of
> straight wire across the space where it used to be. A patch
> cord has much
> better bandwith/$$$, lower maintenance, higher availability,
> and wonderful
> useability. It's just that the security sucks.
I don't give a dam about cutesie toys or what an average Joe User
wants. Yes, a new requirement needs to have justification, and ICQ
just does not qualify ;) Of course you have your standards, but by
preventing yourself to even consider alternatives, you have lowered
yourself to the level of the average user, because they also don't
want to consider a life without ICQ...
> [...]
> Those of us who work in security think we first need to
> settle a more basic
> question, _Whether_ you can implement it in a secure fashion.
> So far the
> answer appears to be No.
Well, then you may not have tried hard enough...
Regards,
Frank
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2
Comment: PGP encrypted email preferred
iQA/AwUBNv3I1Clma9DCzQQeEQJVQQCfVV2Y0qyxC9m9xVXT8mrYpH6aiTAAn0O/
lod1ZYHCs/eFKxyKYBzhXpa8
=tl+g
-----END PGP SIGNATURE-----
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
