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

[David Farber <dave () farber net>]

BTW Steve , Bill and Jon are all experts in security (and two were my 
former students co-advised by me and Jon Smith at UPenn :-)  )

Dave

> Date: Sat, 13 Oct 2001 15:43:51 -0400
> To: farber () cis upenn edu
> From: Steve Crocker <steve () stevecrocker com>
>
>
> Re TCSEC vs Microsoft, I'm in rough agreement with Bill Arbaugh but differ 
> on a couple of points.  let me line things up a little bit differently.
>
> About TCSEC rated systems, Bill said:
> > >         1. They were way too expensive when compared to commodity goods.
> > >         2. They were unbelievably difficult to use and even worse to 
> > > manage.
> > >         3. They used out of date technology and software.
>
> All true, but the situation was even worse.  Continuing with Bill's list:
>
> 4. Even systems which conformed to the TCSEC weren't secure in terms most 
> of us would expect.  When the Morris worm struck in 1988, I looked through 
> the TCSEC to see whether TCSEC compliance would have provided 
> protection.  Attention to the correctness of the code, as opposed to just 
> the design and the inclusion of access controls, didn't come into play 
> until at least the B2 level.  Even at that level, I doubt the level of 
> code review necessary to satisfy the NSA evaluators would be sufficient to 
> wring out the kinds of bugs that regularly cause security holes in our systems.
>
> 5. NSA was almost totally focused on confidentiality.  They had a limited 
> interest in integrity and *no* interest in reliability or denial of 
> service.  It was perfectly ok if a system crashed all the time and was 
> effectively unusable.
>
> And I have to add that Bill's first and third points are wildly 
> understated.  The evaluation process was horrendous.  Inexperienced, 
> untrained government employees were attempting to keep up with the talent 
> and competitive pressures in the commercial marketplace.  They were well 
> intention, but many of their decisions were matters of judgment which 
> varied from one person to the next and were unpredictable, and the process 
> took a very long time.
>
> With respect to why commodity systems have security problems, I disagree 
> with Bill's implication that we should expect security problems in 
> commodity systems.  Microsoft puts enormous energy into its design and 
> implementation process.  There is quite a lot of time between conception 
> and delivery.  Moreover, since they're in a monopoly position, they 
> control the clock.  No one is forcing them to deliver systems with 
> intolerable security.  If the public demanded better security, they could 
> easily apply their attention to the problem and do much better.
>
> To be fair, their systems are quite a bit better than they used to be with 
> respect to frequency of crashes.  It's now common to use a Windows system 
> all day without rebooting.  (Of course, it's common to leave a Unix system 
> running for weeks without rebooting.)
>
> Calling for better development techniques is all well and good, but the 
> single strongest lever, IMHO, is public acceptance.  If the users declared 
> they simply won't pay for a system which comes configured to execute 
> virus-laden mail, Microsoft might change their practice.
>
> There's a possible parallel with the experience in processors.  From the 
> earliest days, it was not uncommon for processors to have small errors in 
> them.  When the SEAC, a pre-1950 hexadecimal computer, was disassembled, 
> it was discovered it had been rounding when the trailing digit was 5 or 
> more, but it should have been rounding 8 and higher.  Similar flaws 
> cropped up in processors over the next four decades, and this experience 
> was well known within the field.  Intel was caught off guard when there 
> was a public eruption about the arithmetic error in its processors a few 
> years ago.  By any objective measure, their processors were as good or 
> better as any had ever been, but expectation from the public had changed.
>
> With the embedding of computers in appliances and the appearance of 
> appliance-type computers, e.g. Palm, I expect the public's expectation of 
> reliability and security will shift considerably.
>
> Steve
>
>
>
> At 02:30 PM 10/13/2001 -0400, David Farber wrote:
>
> > > X-Sender: waa@localhost
> > > X-Mailer: QUALCOMM Windows Eudora Version 5.1
> > > Date: Sat, 13 Oct 2001 14:07:25 -0400
> > > To: farber () cis upenn edu, shap () eros-os org
> > > From: Bill Arbaugh <waa () cs umd edu>
> > > Subject: Re: IP: Re: -RE: GOVNET? Not the brightest idea.
> > >
> > > Dave,
> > >
> > > I need to take issue with Shap's point.
> > >
> > >
> > > > > I am no defender of Microsoft, but the statement above is unfair in the
> > > > > extreme. Microsoft is indeed incompetent at security, but they haven't yet
> > > > > achieved a monopoly on incompetence. The fact that we have no secure
> > > > > commodity operating system is a direct result of fifteen years of Federal
> > > > > policy.
> > >
> > > The exact cause of why TCSEC rated systems died is debatable. While I'm 
> > > certain
> > > that export policy reduced the sales of these systems, it did not cause 
> > > their death.
> > > I used numerous TCSEC rated systems over the years, and I found them wanting
> > > in several ways:
> > >         1. They were way too expensive when compared to commodity goods.
> > >         2. They were unbelievably difficult to use and even worse to 
> > > manage.
> > >         3. They used out of date technology and software.
> > >
> > > These are the reasons why TCSEC rated systems failed to be successful
> > > products. Their sales within the US DOD were dismal even though their use
> > > was mandated. They failed as a product because something else was always
> > > cheaper, faster, and easier to use.
> > >
> > > The reasons why these systems failed are the dual of why MS has succeeded,
> > > and to some degree why commodity software usually has security problems. 
> > > Vendors
> > > are trying to ride the wave of newer and cheaper technology. This 
> > > creates a rapid
> > > design and development process which introduces design and 
> > > implementation errors-
> > > sometimes security critical errors. These same vendors try (although 
> > > some may argue
> > > they don't succeed) to make their systems and software easy to use- ease 
> > > of use and
> > > security are typically at odds with each other.
> > >
> > > In short, the current process of designing, building, and even managing 
> > > systems are
> > > at odds with achieving a high degree of assurance. The question is: can 
> > > we find ways
> > > to develop systems and software rapidly such that they have a high 
> > > assurance and are
> > > easy to use and manage?
> > >
> > > It's easy to blame the usual suspects (Microsoft, and the Government) in 
> > > this situation.
> > > But, neither are at fault this time.
> > >
> > > Bill
> > >
> > > ----------------------------------------------------------------------------------------------------------------------------
> > > William A. 
> > > Arbaugh                                                        301.405.2774
> > > Asst. Prof., CS and 
> > > UMIACS                                  http://www.cs.umd.edu/~waa
> > > ----------------------------------------------------------------------------------------------------------------------------
> >
> >
> > For archives see: http://lists.elistx.com/archives/interesting-people/
>
> ----------------------------------
> Steve Crocker Associates, LLC                 Bus: +1 301 654 4707
> 5110 Edgemoor Lane                            Fax: +1 202 478 0458
> Bethesda, MD 20814                            steve () stevecrocker com


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