Home page logo

basics logo Security Basics mailing list archives

"It's ok we're behind a firewall"
From: John Brightwell <brightwell_151 () yahoo co uk>
Date: Wed, 19 Feb 2003 10:58:20 +0000 (GMT)

"It's ok we're behind a firewall"

The response I received from a DBA when I forwarded an
email detailing a security vulnerability in a
particular database application.

And not the first time I have heard this response when
cautioning about security vulnerabilities.

I want to raise the security awareness of the company
so that they start to understand that a Firewall isn't
absolute protection.

1. Still a large majority of computer crime (data
theft, damage etc) is caused by people who have access
to internal systems ... is there anywhere that I can
get facts and figures to support this?

2. In an average company it's not so difficult to gain
physical access - how closely are the staff vetted let
alone third-party contractors. Stick a boiler suit on
and carry a big toolkit and many people will hold a
door open for you!

3. Firewalls can be breached or misconfigured ... it
only takes a change made in too much haste to open
port 0023 instead of 50023 and telnet access is opened
from the Internet.

4. Firewalls can be bypassed - traffic that is
legitimately allowed through may include an exploit -
such as viruses carried by email (you may be unlucky
and be hit by the virus before your AV software is
ready for it). I know of a company which had to shut
down its internal LAN for a number of days while they
tried to eliminate the Nimda virus - they suspect that
the virus initially got in via email but spread
because a large number of staff had set up IIS on
their desktop to disseminate documentation ... I bet
if anyone had debated the security of them running IIS
they'd have said "It's ok we're behind a firewall")

I'm keen to apply a greater level of security to
internal systems.

1. Caution against moving to the 'cutting edge' OS or
latest version of software until the initial rush of
bugs (including security bugs) have been found 

2. Regular patching for security issues. Given the
number of vulnerabilities being posted I think it may
be unreasonable to expect patches to be installed as
soon as they're posted - each change will require a
degree of administration (testing etc) but perhaps
scheduled quarterly updates... If a successful exploit
is found and executed within three months of the
posting of the vulnerability then we're toast (but
it's not as embarrassing as being hit by an exploit
that was reported 6 months ago)
Do you schedule patch updates (what's the preferred

3. Control the build of internal systems so that
unneeded services are disabled. Where one-off security
measures can be implemented at a low cost this will be
done (we have to bear in mind that a high recurring
cost - whether it be licenses or administration costs
my not be cost justified by the risk)
I've already posted a query about this - I'm inclined
towards a generic internal build for each OS (Unix,
Microsoft) but with only required services enabled.
this isn't ideal from a security perspective because
there are packages available that may be used for
nefarious activity but we have to strike a balance
between security and cost of administration (with a
very large number of internal systems it becomes quite
expensive to maintain a great variety of

4. Raise staff awareness of security issues (this is
actually the most important factor of all).

The question is, how to approach the staff who've got
their heads buried in the sand.

Are there any sites out there with the facts and
figures about internal exploits and cautionary tales
about disgruntled employees or IT savvy nighttime cleaners?

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]