Re: [fw-wiz] ASP/Hosting Architecture

From: Chris Pugrud (chris_at_pugrud.net)
Date: 11/18/04

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

    --- "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


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

    Relevant Pages

    • Re: My Frustrations
      ... Again, this is not an issue of communication, or geeks versus business men. ... This is not an issue of proving or demonstrating the quality of ones self or service. ... This is an issue of enabling the customer to make the right decision. ... landing the customer in a very poor security state, ...
      (Pen-Test)
    • RE: My Frustrations
      ... to communicate the value of what we do in business terms. ... That problem confuses the customer and often times ends up ... landing the customer in a very poor security state, ... presenting the same face and message as the quality provider. ...
      (Pen-Test)
    • Re: My Frustrations
      ... While I appreciate your response I only partially agree with you; and frankly I wasn't asking you for a lesson in business. ... That problem confuses the customer and often times ends up landing the customer in a very poor security state, then they wonder why they get hacked. ... At that point it is not a matter of the good provider conveying the message better its a matter of the customers learning how to tell fact from fiction, but they can't do that without being educated first. ...
      (Pen-Test)
    • Re: Encryption of printer files
      ... print jobs. ... One of my security conscious customers decided to lock their dot ... were printing out customer lists and selling them to competitors. ... Each dot would be re-positioned somewhere near the proper location. ...
      (comp.unix.sco.misc)
    • [REVS] Security Considerations for Web-based Applications
      ... Get your security news from a reliable source. ... consequences of this ranges from the erosion of customer confidence in the ... of poorly implemented host naming procedures or web-application URL ... The attacker may choose to inject ...
      (Securiteam)