Re: httport 3snf

["Paul D. Robertson" <proberts () patriot net>]

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 
it.

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
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () patriot net      which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards