1999-03-26-06:41:59 Frank Knobbe:
> > [...] But let's face it, MS PPTP, RRAS, and NetMeeting are just too
> > partially designed and/or implemented to be allowed to pass traffic
> > through the outer membrane of any organization that has internal data or
> > systems that are not for public consumption or operation. Period.
>
> Ouch. You won't gain any clients with that attitude.
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.
> 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".
You see, there are multiple pressures:
- 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.
- 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.
- 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.
- 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.
- You don't have an infinite budget of either time or money.
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. Remote access, through ssh
tunnels through the firewall, to sacrificial machines in the DMZ can be one
way to set this up.
> > [...] Products with no real predictable way to ensure their traffic's
> > content and origins (Cu-See-Me, and others, included) should be
> > re-examined by their designers if they are to be used for business
> > purposes inter-organization.
>
> So, you suggest filtering and disallowing them?
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. 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.
> You may as well disconnect the firewall.
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.
> But rest assured, folks are reviewing protocols, see above.
I rest assured. My assurance comes from the knowlege that nobody can burgle
the machines. It requires that I keep in touch with security developments, but
by drawing the security line out a fairly conservative stride this side of the
ragged edge, I get very few panics, and no actual intrusions.
> Again, I'm baffled by the level of paranoia that is present among
> current security practitioners.
Don't worry, you don't need to understand it, not unless you want to work as a
security practitioner at a site that cares about security. Continue to avoid
doing that and you can just ignore us.
> People have to realize that a) nothing is secure out of the box, b) anything
> can be implemented to fit someone's needs.
Surely, nothing is secure out of the box, but it is _not_ true that anything
can be implemented; given real limits on implemention time and money, you end
up with a very sharp tradeoff, and implementing many things within avaioable
resources would leave unacceptable security risks.
> We should not try to implement the tightest security controls possible, but
> strive for a sound implementation with the least restrictions of use and
> still an appropriate level of protection.
I'd say instead, we should always implement the tightest security controls
possible, because the tighter the controls, the less likely you are to be
caught vulnerable in the continuously-evolving security landscape we live in.
"The tightest controls possible" ends up being constrained by user demand, so
the real line ends up being drawn by negotiation with the users.
> The issue here is not NM or the protocols it's using, but how you can
> implement it in a secure fashion.
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.
> If that means to set up a Proxy Server, that can dynamically open ports,
> behind, before, or next to an existing, static rule firewall, then so be it.
> Open your mind, and the bytes will follow...
And the burglars will follow hot after the first few bytes.
-Bennett
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
