NETWORK PRESENCE ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT
 


Search
display results
words begin  exact words  any words part 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FW1] somewhat off topic-opening outgoing high ports



Greetings!

Darrin Johansen schrieb:

> The security team at my company is coming under increasing pressure to
> start opening all sorts of outgoing port numbers and protocols every
> time a project manager decides to use a piece of software that needs
> internet access. This is becoming a real problem for us, and I would
> imagine it is for many people? A lot  of this software is
> client/server that has been 'adapted' for use over the internet etc

Who is responsible for IT security in your company - that will have to
be a suit, not a techy?
THAT is the person that has to give his/her okay. He should be at least
somewhere near CEO level as he is organizational responsible for all
security  (read: keeping his head on his shoulders - or not). Make
legally sure that either the IT-Security-Chief's or the PM's head will
be rolling in case of problems.

If there is any protocol to go in or out, request a formal security
audit and risk analysis of the proposed application (you have a
formalized change request procedure, do you?!!). Let the project manager
sign a responsibility/liability waiver where he accepts all risks and
liabilities (regardless cause) that come from the application going in
or out.

About tunneling it via HTTP:  most protocols do not tunnel via real HTTP
but only with TCP/80.  If you enforce the useage of a proxy or
proxy-firewall (Raptor, Gauntlet etc.)  or activate the FW-1 security
servers (create an "empty"  HTTP ressource and use that) most "tunneled"
protocols won't be able to pass through the gateway.

Ah, and if some PM _insists_ on using tcp/80 for his protocol, he will
have to sign the waiver mentioned above - where he assumes all
responsibilities and liabilities that come from (mis)use of port 80.
Someone downloaded a "grettings".EXE from web that destroyed data? No
problem - here's the PM that allowed tcp/80...   ;-)


> If anybody has any links or info it would be gratefully received.
> Opinions obviously welcome, but please state the type of company or
> situation your firewalls are used in if possible etc

I have worked as Sr. IT Security Engineer for KPMG (audit, tax/legal &
consulting) and GlobalOne (telecommunications), now DeTeWe/DiSCON's
(information systems & consulting) Project Manager IT Security - all
Germany. Worked mainly with Raptor & Checkpoint and various proxies.
<plug>Did I mention that we do security consulting
(http://www.discon.de/) like you asked for?</plug>



> Sort of questions we get is: (all referring to outgoing ports, most
> are tcp, not all)
> "We let browsing happen on port 80, why not other applications on
> other ports?"
> "We use http on port 80, why not http on port 16384? Or indeed any
> protocol?"
> "What's so bad about using just any old port, surely they are all the
> same"
> "What are the security concerns or implications then?"

See above: they will have to accept to be liable for all that comes
through "(t)his" port - and thus for other applications, too.  No
exceptions or fingerpointing allowed: liable for ALL that comes through
that hole, regardless what. So either they need the permission of the
orginally responsible person - or sign the "full" waiver, simultaneously
& implicitly accepting an unlimited (!) bail/surety(voc?) for the other
application, too. I guess they will understand that this way (more)
easily.

Bye
    Volker

--

Volker Tanger  <[email protected]>
 Wrangelstr. 100, 10997 Berlin, Germany
    DiSCON GmbH - Internet Solutions
         http://www.discon.de/




================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================



 
----------------------------------

ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT SITE MAP LEGAL
   All contents © 2004 Network Presence, LLC. All rights reserved.