Re: [fw-wiz] httport 3snf

From: Paul D. Robertson (
Date: 10/22/02

From: "Paul D. Robertson" <>
To: Duncan <>
Date: Tue Oct 22 07:09:02 2002

On Mon, 21 Oct 2002, Duncan wrote:

> Having worked in the Firewall support role at several companies, I need to
> vent^H^H^H^H share two experiences that are at difference with the
> above.

I'm just going to add my commentary and perspective on the sorts of issues
you've faced. Hopefully some of it will help someone somewhere,
otherwise it's just a good time to rant...

> At a software development firm (Dot Com) related the policy was
> written to protect property (both physical and intangible). Abuse of
> resources was prohibited.
> But if a developer had a need (or made a request) to open FW ports, or gain
> IM access, "no" was not acceptable, but rather how fast the request
> was completed. As most developers realize, tying a deadline to any
> request is the best way around restrictions or "policies".
> You may just find yourself on the receiving end of a written reprimand
> from your CIO directed at you from the CEO of the company.

I had my CIO approve my security policy. This meant spending *lots* of
time educating him about Internet risk. When he understood the policy
from his perspective, he also understood the fact that enough exceptions
to policy were going to kill _having_ the policy. I had folks attempting to
tie requests to advertising deadlines for newspapers. They often declined
the "get out of your chair, and walk over to the machine in the corner
that's isolated on the DMZ" option though- amazing how an uncomfortable
option changes the priority and necessity of a request sometimes.

Trying to tie requests to deadlines, revenue or things like that tend to
require thought-out responses, as well as rounding execs into rooms and
explaining things to them -for instance, I'd have spent some time with the
head of development explaining that I'd be happy to build the correct
infrastructure to keep the company secure and permit business-critical
things to happen, but that I wasn't going to swiss-cheese my security
policy because of a lack of foresight on the part of his developers.
I'd explain to him the costs of handling last-minute requests versus
proper planning and also find out his threshold for taking responsibility
for the actions of his developers and their requests as it impacted the
whole business. My bet is that after the right conversation, you'd find
that the requests would all go through that person and be fairly limited
to real requests, or you'd be drawing up a "development network" plan that
could quantify the costs of risky behaviour and isolating the company from

There's also a very good "at what point is the firewall now useless"
discussion that needs to be had with the CIO in regards to having multiple
exceptions. There have been a few times when I've offered to "remove that
pesky firewall and make things really easy to do." Nobody's ever taken me
up on it. Once they understand that firewalls work by blocking and that
means the more they block the better they work, it's not usually a
difficult thing to get them to coral their users down.

Also, there are last-minute requests that can have a limited lifetime,
policy changes don't have to be permanent. A fall-back position of "Ok,
we'll take that risk for the next two weeks from 9-12am" may be better
than no fall-back at all.

Just keep in mind that in some environments, the precedent of giving
ground at all will eventually consume you.

> Supporting FW's in the corporate offices of a large ISP (now gone),
> the policies required business justification for opening additional
> ports, and or relocating segments in front of the firewalls. Note that
> as a ISP, we were the daily target of hacking attempts.
> The firewall was set to transparently proxy connections for http
> (80,443,8080) to unlimited destinations. This seemed to work for all
> 300+ employees. But IT had a problem, they could not download drivers
> from HP support. This was a critical problem for them. Their suggestion
> (request) was to open the FireWall to allow all (TCP ports >1024)
> outbound from their class C. to any IP as they could not provide me
> with a list of IPs for HP support.
> The suggested workaround appeared simple:
> a: Configure your browser to proxy via the FW ip.
> b: Use dialup, we are a ISP and its free.
> Management was informed of the risks. The director of IT support informed
> my director that it didn't sound too risky to him to just open up the ports.
> Besides the IT desktop support people would have to remember to turn on
> proxy support when they needed.

That's one of the reasons I refused to go to transparent proxy support.
If people have to remember to configure a machine to even get Internet
access, it was a good thing.

In this specific case though, I'd either have (a) had them always use a
non-transparent proxy [done this in a few places], (b) offered to mirror
the driver site [done this twice before], (c) offered to open the ports
for the duration of a request [never had to do this], or (d) offered an
"on the DMZ" PC they could use for downloading drivers and whatever other
things they wanted [done this a few times.]

The idea that the business has to take a full-time risk for an event
that's probably rare isn't good.

Finally, there's no way in hell the director of IT support would be a risk
decision maker in any policy I wrote. The risk for the entire company
just isn't down at his level.

> Management felt the added risks were justified versus slowing down desktop
> support, since we had not had anyone actually ever breakin.

One of my constant quests was to get executive management to understand
that the reason we'd had no break-ins was because of our security policy
and its enforcement. Fortunately, there have always been plenty of
counter-examples, so passing e-mails about high-profile break-ins and an
explaination of why our security policy stopped a particular vector to the
CIO every couple of months was really good.

I spent a good portion of my "$important
person/department/partner/advertiser/customer" wants $silly_thing time on
long written responses to such requests that clearly labled and landed the
decision point at executive managment and clearly pointed out that making
such a decision would be clearly against my advice.

Understand that a part of that was a risk assessment on my part
career-wise. I'd purposefully skip my boss at the time and go right to
the CIO because he was an officer of the company. In a large company, you
don't have to explain the personal risks such a person takes in making
such decisions against professional advice (but this ploy generally only
works if you're in a publicly traded company.) Only once did my boss go
ballistic over the corner I'd backed the CIO into on a given decision, and
that was something I believed strongly enough in to offer to go find
another job over.

My security policy clearly enumerated the decision tree, process for
exceptions and rules, as well as the implementation details (added as a
last minute flash of brilliance that allowed me to restrict the
distribution of the document the way that having two seperate documents
wouldn't have.)

> At least in these two companies the policy only went so far as to
> interfere with some claimed business need, and we had a exception.
> Working for smaller companies (<500 employees) policies are usually
> a after thought, and may have been written by some manager in IT dealing
> only with abuse of the desktop itself. I have been at 3 Tech. companies
> where each has the following section in their policies:

First of all, policy *has* to have support from the highest levels, or
it's going to be useless. Secondly, you must be able to articulate risk
well to get a good policy and to get backing for enforcement.

> "XX. Internet usage is only for approved business purposes. Personal use
> (access) is prohibited."

In a lot of places, having a policy that's not enforced (and I've yet to
be anywhere that had a prohibition rather than a few restrictions on
personal usage) is worse than no policy at all. I'd have spent some time
detailing the legal risks, then presented them in writing.

> This was in (2) Software (Internet) development and one ISP company
> policies.
> On the other hand having worked in a AeroSpace biggie where there are
> more work rules than one can read in a month, policies tended to be
> better enforced. Or atleast it was much harder for a requester to get
> enough management support to force a FireWall change.

Smaller companies are a much more difficult nut to crack because often the
environment is more "friendly" and they mostly haven't gone through the
trials that large companies have (because any one of them would wipe a
smaller company out of business.)

Small companies in a rapid growth phase tend to have to make risk choices
that aren't always the best from a risk perspective too. I'd probably
have real trouble being the firewall admin at some places because my
personal risk profile wouldn't match the company's. There's a point at
which either the admin or the company has to give. I've been in the
position that I've always been able to make the company give. I doubt
there was more than a 30 day period at one point for about a year
where I didn't offer to resign, turn the firewalls over to someone else,
ask someone who wanted an exception to design a way to secure their
exception if they were so much smarter about the security policy than I
was, etc.

There's also a distinct advantage to going in to a job knowning you'll do
firewalls. When I started doing firewalls, I got the extra responsibility
added to my "day job" because some manager had made the firewall decision
and I was the only one in the building who knew Unix, so the guys who he
"trusted" more than me gave me the root password rather than having to try
to work in an environment that didn't interest them (they were datacom
folks.) Since I didn't have the luxury of going in negotiating my
position, each part of the executive support for my policies, as well as
the overall handling of that stuff had to be eked out over time.

Some people were mad at me for *years* when I wouldn't approve an
exception, they got another "Internet" division in a meeting, and the
admin there agreed with me, then they drug their CIO into the room and
asked again, and I still said "No." They didn't want to budget to "do it
right," and "right" in my book didn't included doing it from their
desktops. That started a multi-year project to decouple the largest
business unit we had and about 1700 users from the corporate network. It
also sparked some seperate firewall purchases. I still remember the
meetings with them once they realized that their culture of politics and
acomodation uber alles would land them responsible for their own network
security policy and its enforcement. None of them was willing to be "The
one who says No." and they could finally realize the downstream effects of
that. At that point, it was too late for them to backpedal though, and
the most vocal of their seperatist movement had already moved on to
another company. Whoops!

Paul D. Robertson "My statements in this message are personal opinions which may have no basis whatsoever in fact." Director of Risk Assessment TruSecure Corporation

Relevant Pages

  • Re: Messenger Audio/Video with ISA 2004
    ... Technically speaking, if this needs to be supported through the firewall, ... Therefore, the external client can ... Microsoft CSS Online Newsgroup Support ...
  • RE: Sandboxing
    ... the 3Com Embedded Firewall would be extremely useful and enabling (in ... your case) when you look at it in a VPN context. ... This security policy will accomplish quite a few things: ... During the Policy Server installation, ...
  • Re: Why Deportation?
    ... On second thought...a takeover of Mexico by the US would be one ... Is that the specific policy you support? ... We cannot even support the occupation in Iraq, ... time we should go to war with a country. ...
  • Re: [fw-wiz] stopping bots from phoning home
    ... well it works fine on my dsl connection! ... the majority of support calls that we receive are from the very ... > with the newer IM clients that do IRC. ... that having a firewall on the box that can see which program is trying to ...
  • Re: Problem with EZ Antivirus
    ... >> internet access through your firewall. ... >> If you continue to receive the 'fatal error 3' message when trying to run ... >> Windows Firewall - Please be sure that the Windows XP firewall on your ... >> Please send the ezreport to support now. ...