RE: Sources for Extranet Designs?

["Mitchell Rowton" <mrowton () bdo com>]

I *think* this depends on what you tell your customers when they sign
on.  If they signed an access form that says "yada yada, we are not
responsible for security" then it doesn't seem like you would be liable
at all.  Providing that you attempt to provide reasonable security
measures.  What is reasonable is up to lawyers, judges and such.

But I would think that if you had a extranet policy and connection
agreement (see link) you would be fairly safe with a good attorney.
http://www.securitydocs.com/links/detail/345

I (and most of you) would also consider having a firewall to enforce
the security controls outlined in your policy to be reasonable.  But how
much money to you spend to secure customers from other customers?

Mitchell

> > > "Bob Alberti" <alberti () sanction net> 02/23/04 03:08PM >>>
One thing I always wonder about in Extranet designs:  how liable are
you
(the host of the Extranet) if two of your Extranet customers are
competitors?  If Customer A can hack your Extranet to, for instance,
inspect
Customer B's orders, or even to hack Customer B's network, how liable
are
you for not providing a more secure Extranet environment?

Its one thing to protect the host organization from Extranet clients:
its
another entirely to protect clients from each other.

-----Original Message-----
From: firewall-wizards-admin () honor icsalabs com 
[mailto:firewall-wizards-admin () honor icsalabs com]On Behalf Of Wes
Noonan
Sent: Monday, February 23, 2004 1:31 PM
To: 'Baumann, Sean C.'; 'R. DuFresne'
Cc: 'Paul Robertson'; firewall-wizards () honor icsalabs com 
Subject: RE: [fw-wiz] Sources for Extranet Designs?


> 1.) If you say you should never allow access to resources on your
> protected or internal network, how do you handle giving access to
> services that reside on machines that cannot be duplicated (i.e.
> expensive mainframes)?

There are a couple of approaches that I can think of off hand. Approach
1 is
to design the services with extranet connections in mind. Simply put,
maybe
the mainframe isn't the right place to house that resource. This is
probably
not the answer that you want to hear though. Approach 2 is to accept
that
you have a business limitation that is going to force you to implement
a
less than ideal security solution. At that point, you mitigate it.
What
precise ports need to be opened from the extranet to the internal
resource
and grant *only* that access. If they need SQL access but not NFS
access
then make sure that your firewall only permits SQL traffic to pass
between
the two networks. Things like that.

> 2.) Do most companies require routable address on their extranet?
> Currently we use RFC1918 address for our extranet, but we see that
this
> will become a problem in the future as we add partners.

Depends. Assuming that you are going to be using firewalls and
advertising
your internal resources as something else (through the use of NAT,
etc.)
then you can do that and make the routable addresses what the extranet
partners think they are going to connect with. That being said, you
can
pretty much pick any RFC1918 address space at that point and use it in
a
similar fashion. The obvious alternative is that someone will need to
change
their address space.

More detailed design you will probably have to pay me for. :-)

One thing that this scenario really graphically depicts is why
separation of
resources is such a valuable objective. Sure, it sounds really nice to
have
all your stuff running on a mainframe running Linux hosts but these are
the
kinds of security problems you will then run into. (feel free to expand
this
statement as you see fit - i.e. integrated firewall/ids/content
filter/spam
control/virus scanning or separate switches vs. VLANs).

HTH

Wes Noonan
mailinglists () wjnconsulting com 
http://www.wjnconsulting.com 
Hardening Network Infrastructure - A concise how to guide
Available Spring 2004
Order at http://tinyurl.com/2nof4 



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

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


NOTICE:
The contents of this email and any attachments to it may contain privileged and confidential information from BDO 
Seidman, LLP.  This information is only for the viewing or use of the intended recipient.  If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution or use of, or the taking of any action in 
reliance upon, the information contained in this e-mail, or any of the attachments to this e-mail, is strictly 
prohibited and that this e-mail and all of the attachments to this e-mail, if any, must be immediately returned to BDO 
Seidman, LLP or destroyed and, in either case, this e-mail and all attachments to this e-mail must be immediately 
deleted from your computer without making any copies thereof.  If you have received this e-mail in error, please notify 
BDO Seidman, LLP by e-mail immediately.

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