Re: [fw-wiz] ASP/Hosting Architecture

From: Chris Pugrud (
Date: 11/18/04

  • Next message: Bennett Todd: "Re: [fw-wiz] Ethics & hiring"
    To: "Paul D. Robertson" <>
    Date: Thu, 18 Nov 2004 11:28:43 -0800 (PST)

    --- "Paul D. Robertson" <> 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

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

    firewall-wizards mailing list

  • Next message: Bennett Todd: "Re: [fw-wiz] Ethics & hiring"