Re: Closed Network Implementation?

[Michael Sinatra <michael () RANCID BERKELEY EDU>]

Doing it on smaller network segments also allows you to separate 
research traffic from administrative traffic and it makes it easier to 
build a Science DMZ (http://fasterdata.es.net/science-dmz/).  You can 
delegate administrative control of firewall contexts or virtual 
firewalls to departments, giving them the responsibility--and 
authority--to further secure their systems.

If you're going to do this, the way that Mike I. and UC Irvine have 
implemented it is probably the best way to do it.  Still, you're 
effectively putting a huge state-machine at your border, and all of the 
fate-sharing that goes with that.  We have found that even with all 
ports open, stateful firewalls can still slow things down for 
large-scale data transfers, which is part of the motivation for the 
Science DMZ.  It's important to be aware of the trade-offs.

And there's still something to be said for the open network.  Such 
networks are not as insecure as you think, because the security controls 
are pushed to layers where they can be more effective with less 
collateral issues (and therefore, fewer attempts to work around the 
controls).

michael

On 03/08/2013 10:04, Harry Hoffman wrote:
> I'm curious as to why people do this at the border?
>
> Why not just on smaller network segments?
>
> Cheers,
> Harry
>
>
> On 03/08/2013 12:28 PM, Mike Iglesias wrote:
> > On 03/07/2013 08:19 AM, Thorpe, Glenn wrote:
> > > Hello,
> > >    I work on the Information Security Team at the University of North Texas
> > > System.  We are currently moving towards a default deny (closed network)
> > > design, and I am reaching out to other institutions to see if they have gone
> > > though this process and any roadblocks or lessons learned that could be shared
> > > with us.  I'd appreciate any input you may have or anyone you could point me
> > > to that may be able to discuss this further.
> >
> > We did this several years ago.  We setup a web page that faculty and staff
> > could use to register systems that needed access from off-campus and what
> > ports needed to be opened (they can also open all ports).  We also made lists
> > of systems that had been accessed from off-campus and gave it to the school
> > computing staff so they could contact the faculty/staff that were responsible
> > for the systems, make sure they really needed the access, and make sure they
> > were registered before the cut-over date.  We did the cut over in phases,
> > doing part of our address space in each phase (we have 4 /16s networks).  This
> > lessened the issues we had to deal with.
> >
> > Registration changes are made to the border firewall at set times during the
> > day (currently 3 times a day, morning, early afternoon, and evening) if
> > anything has changed since the last update.