Re: ASP/Hosting Architecture

[Chris Pugrud <chris () pugrud net>]

--- "Paul D. Robertson" <paul () compuwar net> wrote:

> On Thu, 18 Nov 2004, Chris Pugrud wrote:
>
> > systems were given access to the customer systems.  Customer access was via
> ASP
> > owned equipment, including private T1 lines that were IPSEC (3DES)
> encrypted.
>
> Was this via the CSU/DSU, from the wireline carrier, or done at a
> different layer elsewhere?
The customer conenctions were encrypted because they left our zone of control,
even though they were "private" point to point t1 lines. The IPSEC VPN's were
done with Network Alchemy Hardware.  Network Alchemy was aquired by Nokia and I
hope the capabilities have been maintained.  NA has a really phenominal
automagical load balancing capabilty.  I still have several boxes on my shelf
that I purchased from the company.

The VPN's were done hardware appliance outside of the customer connection
routers, which were kept black.  The first issue was the ease of management,
the bigger issue was dissimilar vendors and technology for security boundaries.
 The security between the customer clients and the customer servers was the
biggest grey area that required some level of faith in the security analysis.

Customers were coming from overlapping RFC1918 internal addresses, but only
going to their specific servers.  The IPSEC SA's were between the specific
servers and the allowed customer client space.  Everything mixed in the grey
waters between the VPN hardware and the core.  We had to trust in the SA's to
restrict the allowed servers because the core rules could not differentiate
between overlapping customer IP space.

I don't feel like I'm explaining it well, but I could be mistaken.

> > I'd be happy to share some more lessons learned, but it's probably more
> > appropriate off-list.
>
> Oh, I dunno- I suppose it depends on what the lessons were and how widely
> you want to share- operational experiences are almost always extremely
> useful in this field...

The biggest lesson I've learned is to not underestimate the capabilities that
stateful firewalling brings to the table for internal security controls over
packet filters.  I wrote an entire thesis based around the security potential
of internal packet filters (and some magic dust :).  I've since rebuilt the
model using stateful (such as Cisco FW feature set) and the model becomes
remarkably simpler.  I've already written the email, I just need to type it in
and send it to the list.

Other lessons.  I've realized that at the time I didn't stand far enough back
to really see some of the implications of the admin compartments.  Moving
forward I would dramatically restrict access to the customer compartments.  Far
too many people, at the time, had full access into the customers.  I've gotten
more appreciation for the chinese wall model regarding software development and
production.

All this has to be balanced.  One of my continuing mantras is that the more
"security" obstacles you put in place that block people from doing "their job",
the more incentive you give them to find ways around your security entirely
(and they will find them).

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