Well, when I analyze this: there are essentially two kinds of data
streams we all have on our systems: a public stream that provides
services like time, weather images, vendor support, and, not to
forget, chatting services like this mailing list.
there is a second stream: trusted messages: ftp/telnet only to/from
certain sites, evtl. a well guarded mail gateway, and firewalls with
back to back clients that lift public traffic into the trusted
domain pretty much break this scheme.
The dilemma is how things are set up here: the best firewall is
useless, when an engineering application requires a socket
connection, or a database requires unprivileged socket access.
Two ways: either build a new back to back client for that
application, or let it through. The second half of the previous
phrase then annihilates the firewall system.
It makes no sense to build a failsafe high protection on the front
and leave the backdoor open. In this case: internal socks
connections, because that's where I guess the connection could have
been made. the design forgot to protect against an unauthorized
connection from the local host.
What made this possible is probably a missing policy: protection in
the sense of bytes and bits does not serve much, when at the same
time there is no policy that validates server software and restricts
what kind of smtp server, telnet, or ftp server the hosts may run
that are directly reachable from the outside. In this very nice
case, the implementors did not look at the software they were
running: | may not fly on a firewall sendmail. Guess 'wizards' is
out by now from most implementations, but: I always try root without
any password first, and you will be asthonished how often this
actually works.
What the point is: to implement firewalls is not enough. A corporate
security policy must enable the network security to regulate the use
of exposed software, like mail clients, time servers, ftp and telnet
servers. System integration must validate what is used, and this is
certainly not on the level of management decisions or business
partnerships, but on bits and bytes.
I guess it is in reality that what failed in the company that
urgently suspended a scapegoat: was the security officer at all
empowered to make any decisions and enforce them, in the area of
system choice, verification, or implementation?
We can implement any kind of software, close all front doors, and do
all tricks possible to achieve the impossible: protect the inside
but be able to reach everybody on the outside. If we are not given
the keys to lock the backdoor too, such incidents will happen all
the time -- and do, mostly without even being discovered.
To me, the security task is not only watch the bits, but the
politics of it too. Both must work, else see the incident.
Mike
|
|
