Yet again we come to a point where we all seem to forget the nomenclature we
agreed upon last year...
David, I beleive what you are discussing is 'Availability' and not
'Reliability.' I think the difference here is that you intentionally trade
system features such as cost and security to get more Availability. If you
work your design and implementation right, then your system might be
configurable enough to allow your customers to choose between cost,
security, and availability. A system which is unreliable is a system which
does not allow the end user or developer to choose between cost, security,
and availability, but simply imposes it because of poor design.
This appears to be the primary battle between the Unix and WinNT camps. From
the Unix perspective, Unix is a configurable system that is highly
available. It is easy to configure in such a way that it is secure and
available, but to do so will cost you about a week's time from a pretty
descent system administrator (or you can just get OpenBSD...) Unix heads
look at WinNT and shake their heads as it is less reliable than Unix.
Microsoft seems to change the programming and administrative interface to
various system resources every 6 months. You can therefore not plan on what
tools you'll use with NT two years from now. So, you sacrifice reliability
for cost. Installing an NT server is less expensive than a Unix server,
because you can get your secretary or a high-school student to install NT,
and you don't have to worry about it, there's no configuration that you have
to do. You just wait for McAfee or NAI to publish the latest version of
their software and have your secretary install it.
Having administred large networks of Windows and large networks of Unix
machines, I think I would have to say I prefer Unix if I have a competent
staff. It is much harder to mitigate the risk with a network of Unix
machines if you don't have compentent administrators. That said, one system
administrator in a Unix network goes a whole hell of a lot farther than a
single administrator in an NT network. If you eliminate NIS from your
network, you can get even better results. In '93, I was the administrator
for a 2000 node NeXT network spanning three countries and five time zones
(though 98% of the systems were in the states...) In conjunction with a
person to handle hardware issues, a person to handle local network issues,
and a person to handle WAN issues, I was the only "system administrator." A
staff of four people supporting 2400 users on 2000 machines across a WAN is
unthinkable in the WindowsNT world. This is why I'm probably going to buy me
another Macintosh... NeXTStep has finally returned, and I can now get a
machine which will run mainstream apps, and in a pinch run Windows Apps...
oh heck.. now I'm just bitching...
So, the moral of my story is... Reliability and Availability are similar,
but not the same thing. The same way that a Trusted system is not exactly
the same thing as a Secure system. You never know if your system is reliable
until you install it and start having requests hit it. However, you can
strive to make your system Available, and there are several well known
development methodologies to enhance the probabilty that you'll make an
available (and reliable) system.
-We now return you to the previously scheduled program...
-Matt H.
Alzo Spracht David Wheeler:
> > From: "mshines" <mshinesat_private>
> > To: <secprogat_private>
> > Subject: FW: Repost
> > Date: Mon, 14 May 2001 13:00:10 -0500
> > Message-ID: <008301c0dc9f$b8302e50$5565d280at_private>
> > We don't practice what we preach? :)
> >
> > New software = failed software...
> >
> > Mike Hines
> > mshinesat_private
> >
> > RELIABILITY would be one criteria for secure programming... it would
seem
> > to me.
>
> Well, your statement appears to be mostly tongue-in-cheek, but there's
> actually a valid issue hiding here. I don't agree with your statement.
>
> Security requirements vary, depending
> on the use of the system, and might include:
> * confidentiality/secrecy ("an attacker can't read my stuff")
> * integrity ("an attacker can't change my stuff"), and/or
> * availability/defense from denial-of-service ("an attacker can't keep
> me from using my stuff").
>
> Not all users require all of these requirements to the same degree.
> Indeed, can trade between these. For example, a system that tries to
detect
> "suspicious" situations, and prevents you from reading your data in such
> cases, may be very unreliable... but have great confidentiality.
> Whether or not that's okay depends on how the system is being used, but
> in some contexts this would be a _more_ secure system.
>
> We've had a "reliability vs. security" definition debate before.
> I guess what I'd contribute is that software developers need to
> examine the intended environment & determine the best trade-off BEFORE
> the software is developed. If there's no single answer for the intended
> market/user base, the code needs to be configurable so that
> the user/administrator can select the best response to the circumstance.
>
>
>
This archive was generated by hypermail 2b30 : Thu May 31 2001 - 18:41:31 PDT