IP: -RE: GOVNET? Not the brightest idea.

[David Farber <dave () farber net>]

> Thread-Topic: GOVNET? Not the brightest idea.
> Thread-Index: AcFR42gGj6jRbRowSruREXpQcd1IgwAggh7g
> From: "Peter Schamerhorn" <Peter.Schamerhorn () corel com>
> To: <farber () cis upenn edu>-



> Dear Mr. Farber,
>
> Although Mr. Metzger does bring up some salient points, I believe I
> would have to ask him to step down from his anti-MS soapbox for a minute
> so that I can see the crowd.  I know MS might claim otherwise, but I
> thought that the majority of web servers WERE still running *nix ( i.e.
> non-MS kit), but I digress.  I believe Mr. Metzger makes some pretty
> amazing assumptions about what can and will be done to address this
> problem.  Addressing a quote from the original article:
>
> "After one day on the job, the president's cyberspace security adviser
> asked computer companies Wednesday to help design a new secure
> telecommunications network for government use."
>
> I do not believe that Richard Clarke said 'using currently available off
> the shelf solutions' anywhere in his request.  I think that when you are
> asked to 'design a new secure' network, you have a fair amount of leeway
> in the types of proposals you can submit.  As we all know from reading
> initial specs, and often poorly written ones, the technical requirement
> can often be fullfilled in a vastly different manner than the functional
> spec may or may not imply.  I would be willing to bet that (and I have
> some ideas myself how this might be accomplished) the bright minds at
> the various companies such as Cisco, Nortel, Lucent (Bell Labs?), AT&T
> etc can find a way to fullfill the intent of the functional requirements
> outlined by Mr Clarke, and probably manage to make some money at it as
> well.
>
> Well.. I think I've now spent my two cents worth.. so let the debate
> rage on....
>
> Peter Schamerhorn
>
>
> -----Original Message-----
> From: David Farber [mailto:dave () farber net]
> Sent: Wednesday, October 10, 2001 7:28 PM
> To: ip-sub-1 () majordomo pobox com
> Subject: IP: GOVNET? Not the brightest idea.
>
>
>
> >To: farber () cis upenn edu
> >Subject: GOVNET? Not the brightest idea.
> >From: "Perry E. Metzger" <perry () piermont com>
> >Date: 10 Oct 2001 19:05:59 -0400
> >
> >
> >FYI, until I started Wasabi Systems, my job was security consulting to
> >large financial institutions.
> >
> > > >A key feature of this network, called GOVNET, is that it must
> > > >be able to perform its functions with no risk of penetration or
> > > >disruption from users on other networks, such as the Internet.
> > > >GOVNET is planned to be a private voice and data network
> > > >based on the Internet Protocol (IP), but with no connectivity
> > > >with commercial or public networks.
> >
> >I hope that they understand that this produces in many ways the
> >ultimate "crunchy exterior -- soft chewy interior" problem that any
> >firewalled system has. As many companies discovered during the recent
> >Code Red problem, even users moving laptops from exterior to interior
> >networks can suddenly infect "secure" networks. You have to prevent
> >ANY data interchange, ANY accidental cross connection of networks.
> >
> >No amount of firewalling would be sufficient for such a network.  It
> >has to have no data interchange (even email) with the outside. No
> >"Secure VPN" access from the outside, given that such software almost
> >never produces "secure" access (what it typically does is make the
> >machine with exterior access an effective hole in security --
> >penetrate it over the internet and you've penetrated the interior
> >network.)  Only an air gap will do, and a completely rigidly enforced
> >one at that, no data or software interchange with the outside.
> >
> >Of course, if such a network is large enough, the biggest source of
> >security problems -- stupid users -- becomes difficult to avoid, and
> >it may become difficult to completely enforce the "no data or software
> >interchange" rule. You can enforce that inside an agency like the NSA
> >but not inside a large chunk of the federal government. Firewalls and
> >airgaps only work if you have a small interior to defend against the
> >outside. When the interior becomes too large, you can't possibly
> >patrol the hundreds of thousands of network access points in the
> >system. Every network jack in every agency with access to this net
> >becomes a potential source of infection.
> >
> >In order to try to enforce such a regime, of course, you'll inevitably
> >have to drive costs of running such a network through the roof, with
> >every piece of software being installed on such a network only after
> >analysis and with substantial amounts of labor by the central IS
> >infrastructure. No innovative programmers or cowboy systems managers
> >can operate on such a network. Without rigid rules, it won't work. Of
> >course, WITH rigid rules, the value of the network to its users will
> >be substantially lower than that of a normal network, since without
> >innovative programmers or cowboy administrators, no innovation will
> >take place and trying to get work done will be painful. "Oh, you want
> >an interior web site to do *that*? Well, sorry, we'll have to take it
> >up with the software committee, next month, after they're done
> >discussing the things in the hopper. Oh, don't even think about
> >setting up transfer of data from your normal department SQL server to
> >the one you have on the interior network -- not after that last
> >stored-procedure based virus."
> >
> >Ultimately, I think such an effort is utterly doomed. Such a network
> >will be valueless AND not particularly secure.
> >
> >I will now say something politically incorrect in the extreme. The
> >reason we face horrible security problems these days on the net is to
> >a large extent (although by no means solely) because we've developed
> >an operating system software monoculture on the internet, with a
> >single supplier being responsible for the overwhelming bulk of
> >software installs.
> >
> >This supplier is about as incompetent as you can possibly imagine at
> >handling security issues, with large numbers of its own machines
> >typically being infected by each new worm hitting the net. If the
> >Federal government wants to avoid having its networks being
> >vulnerable, having a polyculture of systems and software replacing the
> >current monoculture, with systems being connected by open protocols
> >rather than common use of undocumented file formats, is the single
> >most important act it could take.
> >
> >Unfortunately, the major supplier in question will fight any such
> >actions tooth and nail, both with aggressive business practices and
> >with its biggest weapon, the closed and non-interoperability nature of
> >its software. The company in question has shown that it will go to any
> >lengths to gain even trivial incremental market share. It will also
> >contend in all media, very loudly, that it bears no responsibility for
> >the extraordinarily bad quality of its software, which it will loudly
> >contend is perfectly secure.
> >
> >
> >Perry
>
>
> For archives see: http://lists.elistx.com/archives/interesting-people/


For archives see: http://lists.elistx.com/archives/interesting-people/