HDTenEightyP/NetNews huggingface dataset:
From: amdunn@mongrel.UUCP (Andrew M. Dunn)
Subject: QC Department (Was: Stupid Licenses)
Organization: A. Dunn Systems Corporation, Kitchener, Ontario, Canada
Date: Tue, 22 Dec 92 03:08:33 GMT

In article <bhayden.724948146@teal> bhayden@teal.csn.org (Bruce Hayden) writes:
>Well - you may be right. However, the lack of a QC group is in itself
>an indication of a lack of due care. Needless to say though, this latter
>is probably harder to prove in court.

I disagree.  The lack of a QC group just *might* indicate a software
company that's "doing it right".  Making the software engineers who
_write_ the product responsible for

   (a) developing test plans
   (b) design review, and not just at a shallow level
   (c) testing code as it's built, extensively
   (d) veryify the results against the test plan

_and_ making them responsible for fixing their own bugs, too.  That
way they actually get feedback on their code -- all too often they're
on to another project before the bug reports come in.

Several companies also have these folks do their turn on tech support
as well, so they can talk to the users _directly_.  I used to do some
of that, and it was eye-opening, I can tell you!

You wind up with well-rounded software engineers (well, not all of us
look like that...) who understand the implications of their actions,
know how to troubleshoot, and have a pretty good idea of who their
customer (read, target user) is.

And no QC payroll to burn cash on.



Andy
-- 
:-------------------------------------------------------------------------:
:  Andy Dunn           <amdunn@mongrel.UUCP> or <dunn5177@mach1.WLU.CA>   :
:  "AT&T thinks Usenet is an Underground organization" - are we really?   :
:-------------------------------------------------------------------------:
From: frisk@complex.is (Fridrik Skulason)
Newsgroups: comp.security.misc
Subject: Re: Future OS virus immunity.
Date: 2 Jan 93 10:14:18 GMT
Organization: Frisk Software International, Iceland

adam@endor.uucp (Adam Shostack) writes:

>available utility.  While I'm not as familiar with the PC world, there
>seem to be at least 50 major strains of viruses, and I don't know of
>any single program which can stop all of them.

50 ?

500 major strains (families), with around 2000 variants in total is more
like it...


-- 
--
Fridrik Skulason      Frisk Software International     phone: +354-1-694749
Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801
Xref: sparky comp.security.misc:2374 comp.org.eff.talk:8127
From: leonard@qiclab.scn.rain.com (Leonard Erickson)
Newsgroups: comp.security.misc,comp.org.eff.talk
Subject: Re: Stupid Licenses (YUCK!)
Date: 29 Dec 92 00:21:07 GMT
Article-I.D.: qiclab.1992Dec29.002107.4196
Reply-To: Leonard.Erickson@f51.n105.z1.fidonet.org
Organization: SCN Research/Qic Laboratories of Tigard, Oregon.

bhayden@teal.csn.org (Bruce Hayden) writes:

>eoliver@ralph.cs.haverford.edu (Erik Oliver) writes:

>>Because of the variety of IBM-Compatible products out there testing for
>>every configuration is unrealistic, if not impossible.  Even in the Mac
>>world, there are problems that occur because of interactions between
>>INITs and CDEVs with applications.  Are these bugs?

>I think that depends on how common the hardware and hardware combination
>is. If the hardware is anywhere close to common, then I would contend
>that it is a reasonable to test a major product on all of the common
>hardware. 

The problem is that the *combinations* are unmanageable. Say the 10 most
common motherboards, the 10 most common video boards, the 10 most common
TSRs. Plus the 10 most common add-on devices. That gives you *ten thousand*
combinations, assuming only one selection from each class. But some can
exist in multiples. And you actually need to test for more than the
10 most common in some classes. 

It *isn't* practical to test even *most* interactions. All you can reasonably
do is test the some "standard" configurations. (Ones that are known to 
be "the standard" that everything else is supposed to work like)

>I also would contend that once you have serious problems with a specified
>hardware combination (with previous releases or products) then you may
>potentially have a duty to duplicate that hardware combination for future
>QC testing.

Or just list that setup as one that the software *won't* work with.

>Obviously, you have a resource problem here. IBM can afford to basically
>test almost anything imaginable (so why didn't OS/2 work on many non-IBM
>platforms?) A small company can probably only afford to test on a limited
>number of platforms and combinations.

>I disagree. We have the capability today to set an acceptable bug level
>before the release, then not release until we have reached that level.
>That isn't happening in many cases. Either we aren't setting the level,
>or if we are, we are shipping before we get to that point.

I know of one company that is trying to do this, and you should hear
the users scream about the fact that the new version isn't ready. 
-- 
Leonard Erickson		      leonard@qiclab.scn.rain.com
CIS: [70465,203]			 70465.203@compuserve.com
FIDO:   1:105/51	 Leonard.Erickson@f51.n105.z1.fidonet.org
(The CIS & Fido addresses are preferred)
Newsgroups: comp.security.misc,alt.security,comp.dcom.modems
From: breinhar@rams.srg.af.mil (Bob Reinhardt)
Subject: Re: Looking for secure data link recommendations
Organization: ARINC Research, Corp.
Date: Wed, 23 Dec 92 13:09:06 GMT


In article <murakami.9@hac2arpa.hac.com>, murakami@hac2arpa.hac.com (Gary A. Murakami) writes:
|> I have a requirement for secure (DOD Secret) data communications between
|> two sites.  Having been away from the market for while I don't know
|> what is currently available.  Using STU-III serial port is an option
|> but if there is something better (same ease of operations but maybe
|> faster data rates or designed solely for data comm) then I would be
|> interested in knowing about them.
|> ----
|> Gary Murakami       |  murakami@hac2arpa.hac.com
|> Hughes Training Inc.|  murky@hti.hac.com
|> West Covina, Calif. |

-- 

Try the new AT&T Model 1910 STU-III Type 1 (data only) device, it
operates at 14.4 Kbps and is the only such device approved by NSA
for unattended (hence automated) use.  It also includes the Hayes
command set so that you can actually use the thing.  The other biggie
is that it includes SACS, for creating access control lists based
on DOA and/or key codes. -- This is required for use in unattended
mode.  You can try dialing (800) 243-7883 to find out more.

                                 Robert B. Reinhardt, Senior Staff Analyst
  /                 /            ARINC Research Corporation, MS 5-230,
 /__,_  _  o ____  /_  __.  __   2551 Riva Road, Annapolis, MD. 21401
/_)  (_</_<_/ / <_/ /_(_/|_/ (_  breinhar@srg, breinhar%srg@uunet.uu.net
--
                                 Robert B. Reinhardt, Senior Staff Analyst
  /                 /            ARINC Research Corporation, MS 5-230,
 /__,_  _  o ____  /_  __.  __   2551 Riva Road, Annapolis, MD. 21401
/_)  (_</_<_/ / <_/ /_(_/|_/ (_  breinhar@srg, breinhar%srg@uunet.uu.net
From: elee9sf@Menudo.UH.EDU (Karl Barrus)
Newsgroups: comp.security.misc
Subject: Unix Security Survey
Date: 30 Dec 1992 11:16:10 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu


I'm doing a UNIX security survey...

[I know, I know, everybody and their family from an edu site does
 unix security surveys - but mine is for real, so please at least
 read the questions before skipping this message!]

The situation: I may "inherit" the administration (or be responsible
for a larger part of the administration) of some workstations at my
place of employment, so I have a couple of general questions:

1) What security software do you use?

  I am familiar with cops, crack, and tripwire, and plan to use them
all.  Are there any other free security packages I don't know about?
Are there any commercial packages?  I'm curious at how many sites use
cops, crack, and tripwire.

2) Have you ever been the victim of a breakin?  What happened?  How
did you know you were broken into?

  Basically, I am looking for the number of actual breakins and
attempts that are made, typically.

  I am not looking for specific details.  The answers I'm looking for
in the "what happened" area can be quite general: denial of services
(used up significant cpu time), user's email read, user's files
deleted, relay point to another machine, system crash, system files
altered, we were attacked but resisted, etc.  I'd like to have an idea
of what happens on average.

  For the "how did you know" question: law enforcement told us, system
logs showed unusual activity, other site informed us, user complained
about missing files, cracker left message in motd..., unusal behavior,
extra root accounts were found, etc.

3) The network at work is connected to internet - no news, though :-).
If I am allowed to set up anonymous ftp, what steps do you suggest in
addition to what is mentioned in Garfinkel and Spafford's _Practical
Unix Security_?

I appreciate any answers to any of the above questions.  If there is
interest, I will post a summary (statistics only, with no names).

Respond to:

/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/

Xref: sparky comp.security.misc:2365 alt.security:5231 comp.dcom.modems:18548
From: hermit@qed.cts.com (Dennis Keppner)
Newsgroups: comp.security.misc,alt.security,comp.dcom.modems
Subject: Re: Looking for secure data link recommendations
Date: 26 Dec 92 04:45:17 GMT
Followup-To: comp.security.misc
Organization: The QED BBS, Lakewood CA

> >
> >>In article <murakami.9@hac2arpa.hac.com>, murakami@hac2arpa.hac.com (Gary A
> >>|> I have a requirement for secure (DOD Secret) data communications between
> >>|> two sites.  Having been away from the market for while I don't know
> >>|> what is currently available.  Using STU-III serial port is an option
> >>|> but if there is something better (same ease of operations but maybe
> >>|> faster data rates or designed solely for data comm) then I would be
> >>|> interested in knowing about them.
> >>|> ----
> >>|> Gary Murakami       |  murakami@hac2arpa.hac.com
> >>|> Hughes Training Inc.|  murky@hti.hac.com
> >>|> West Covina, Calif. |

The Cypher X-5000 or one of its permutations may meet the requirements. 
Probably the only drawback would be the need for sync modems but the 
throughput and ease of connectivity I believe out-weighs that. Overall 
cost is much less than going SECTEL/STU and if you are set up with an HDN 
drop, it will interface with that too.


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
From out of the north and traveling south its...
Dennis Keppner                      America Online: AFL Dennis or
Lakewood, CA                                        afldennis@aol.com
                                    Internet:       hermit@qed.cts.com
                                    UUCP:           qed!hermit
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Newsgroups: comp.security.misc,alt.security,misc.jobs.offered
From: Michael Higgins <higginsm@CC.ims.disa.mil>
Subject: Job Opportunities at DISSP in INFOSEC
Reply-To: Michael Higgins <higginsm@CC.ims.disa.mil>
Organization: Purdue University
Article-Id: <9212230922.A19357@CC.IMS.DISA.MIL>
Date: Wed, 23 Dec 1992 13:22:10 GMT


[Note: I am posting the following as a favor to Mike.  Please address
questions or replies directly to him and not to me.  --spaf]

    Attention Information Security Professionals:

    The Defense Information Systems Security Program (DISSP) Office of
    the Defense Information Systems Agency (DISA) in Arlington, VA has
    recently announced JOB OPPORTUNITIES for INFOSEC Professionals.

    The Announcements are for:

    Announcement # 92-006 BTP (DR)  Computer Specialist, GS-334-13/14
    (GS- 13 = $46,000+ ; GS-14 = $54,000+ annual salary)

    Announcement # 92-007 BTP (DR)  Computer Scientist, GS-1550-13/14
    (GS- 13 = $46,000+ ; GS-14 = $54,000+ annual salary)

    Announcement # 92-008 BTP (DR)  Computer Scientist, GS-1550-9/11/12
    (G S-9 = $26,000+ ; GS-11 = $32,000+ ; GS-12 = $38,000+ annual salary)

    Announcement # 92-009 BTP (DR)  Computer Specialist, GS-334-9/11/12
    (G S-9 = $26,000+ ; GS-11 = $32,000+ ; GS-12 = $38,000+ annual salary)

    The positions available include incident response; security
    engineering; security architecture; policy, plans programs and
    budgeting; security research and devlopment; security education and
    professionalization; security accreditation, certification, and
    evaluation; and security product review and acquisition

    These positions will only be advertised until 12 Jan 93 so if
    interested do not delay.

    Each announcements is for multiple positions and open to all sources.
    The positions are located within the Metro DC area (the office is
    growing so large we are moving, we just don't know where).

    If interested submit a current application (SF-171) to:
               Defense Information Systems Agency
               Pentagon Service Center (Code BTP)
               Room: MF-634B  -  Pentagon
               Washington, DC  20301

    Be sure to submit your SF-171 no later than the closing date of 12
    JANUARY 1993!!!

    Any questions or a copy of the actual announcements call the DISA
    Personnel Service Center at (703) 693-7686.


    Please pass to anyone you think may be of interest.


    ----  This is not an official OPM JOB announcement!! ----
Xref: sparky comp.security.misc:2364 alt.security:5230 comp.dcom.modems:18507
From: wb8foz@skybridge.SCL.CWRU.Edu (David Lesher)
Newsgroups: comp.security.misc,alt.security,comp.dcom.modems
Subject: Re: Looking for secure data link recommendations
Date: 26 Dec 1992 02:45:30 GMT
Organization: NRK Clinic for habitual NetNews abusers - Beltway Annex
Reply-To: wb8foz@skybridge.scl.cwru.edu (David Lesher)
NNTP-Posting-Host: skybridge.scl.cwru.edu

Others said:
# >>|> I have a requirement for secure (DOD Secret) data communications between
# >>|> two sites.  

and discussion of using DES followed.....

Unless they've drastically changed the rules at NSA, DES is
*not* certified for any form of EO12356 [classified] material.
--
A host is a host from coast to coast..wb8foz@skybridge.scl.cwru.edu
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
Xref: sparky comp.security.misc:2392 comp.org.eff.talk:8191
From: vhalkka@klaava.Helsinki.FI (Vesa Halkka)
Newsgroups: comp.security.misc,comp.org.eff.talk
Subject: Re: Stupid Licenses (YUCK!)
Date: 30 Dec 92 23:18:33 GMT
Organization: University of Helsinki



Maybe this has come out,  I have not read every entry, but what
really annoys me is selling programs with known problems, and
known patches to them, but without the patches.

An example from real life.

As our Sun dealer told me when I tried to get the patches: 

- we give you the patches, if you buy a software maintenance contract.

- And we give the program a 3 month guarantee, and give you patches
to every problem you bump into..

- Or you can BUY all known patches to the product you just purchased!!

It is an unbundled product, and the patches were not in usual
sun patch sites, but I found them after some searching from
 anonymous ftp sites.

The patch collection was 1.6 Megabytes, and the README file listed
*really many* bugs.

--
Vesa Halkka                       -O___/ 
University of Helsinki CC:         (  /   	 vhalkka@helsinki.fi 
Centre for scientific computing:  ~~~~~  	 vhalkka@csc.fi
Newsgroups: comp.security.misc,comp.org.eff.talk
From: tfoley@camaro.uucp (Tim Foley)
Newsgroups: comp.security.misc,comp.org.eff.talk
Subject: Re: Stupid Licenses (YUCK!)
Date: 1 Jan 93 13:30:07 GMT
Organization: camaro

>The three most dangerous things in the world:
>
>	1) a hardware type with a software patch
>	2) a software type with a soldering iron
>	3) a user with an idea
>

  Don't forget my absolute favourite and standby ...
 
  'Everyday Programmers are making programs more and more idiot proof'
 
     'Everyday the Universe is producing more and more idiots'
 
	  'So far the Universe is winning...'     ;)
 
				
		


-- 
  --------------------------------------------------------------------------
               The HeartBeat of America...Yesterdays Camaro Z28 
                             tfoley@camaro.uucp   
     Call the Camaro Linux Pub-access site: 1-416-238-6550 USRobotics HST
    Note: Please, no ftpmail or mailing lists or the host gets annoyed :)
  --------------------------------------------------------------------------
Newsgroups: comp.security.misc
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Future OS virus immunity.
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date: 31 Dec 92 17:48:17 GMT

kludge@grissom.larc.nasa.gov (Scott Dorsey) writes:

> Actually, I wouldn't consider Unix to be typical either.  Yes, it's

Well, my example supposed that the protection in Unix actually works
and that there are no security bugs... After all, it was just a
theoretical example... :-)

> possible for a user to infect his own personal executable, then share
> that executable with another user who then gets his own executables
> infected.  True enough.  But, it's not possible for them to infect
> the operating system unless one of those user executables is run by
> an account with permissions (which should never happen).  The chances
> to spread are greatly reduced, and the chances of mass spread through
> the operating system are eliminated.

This is exactly what I said. The "operating system executables" are
just owned by one of the users. Therefore, infecting them is just as
easy (or just as difficult) as infecting another user. The virus has
to be executed by someone with the proper privileges (the owner of the
files or somebody with higher privileges). And the reduced spread is a
result exactly of the reduced sharing...

> >source code. You do not walk around with infected tapes and do not run
> >the programs on them on different machines, as you do in the PC world.
> >That's why, in multi-user systems the worms and the trojans are of
> >much more concern than the usual viruses.

> This is the case with current Unix systems, but it may not always be the
> case, unfortunately.

Dunno... Once people switch to real operating systems, the viruses
will stop using silly hacks as they are doing now. They will become
better behaved, if they want to spread. But I still doubt that in the
future users will share executables more often than now... Of course,
in this case we might see viruses that cary multiple segments of code,
for most popular platforms - like the Morris worm did...

Regards,
Vesselin
-- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
Newsgroups: comp.security.misc,comp.org.eff.talk
From: phardie@nastar.uucp (Pete Hardie)
Subject: Re: Stupid Licenses (YUCK!)
Organization: Digital Transmission Systems, Duluth, GA.
Date: Wed, 30 Dec 1992 15:58:28 GMT

In article <1992Dec28.002314.21233@news2.cis.umn.edu> charlie@umnstat.stat.umn.edu (Charles Geyer) writes:
>Why can't they just provide a release that fixes the old bugs without
>introducing (known) new ones?  Featurality first is the only explanation.

In many (most?) cases they cannot, because the company has announced a new
release with new features, and the deadline has been set.  In the bad companies,
this has been done by a salesman promising something to a customer before
checking with the developers.  In others, this is done by overriding the same
developers.  In the remainder, this is done by the usual delays in the
development.

-- 
Pete Hardie:  phardie@nastar  (voice) (404) 497-0101
Digital Transmission Systems, Inc., Duluth GA
Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection" 
Position:  Goalie               |
Xref: sparky comp.security.misc:2375 comp.org.eff.talk:8128
From: leonard@qiclab.scn.rain.com (Leonard Erickson)
Newsgroups: comp.security.misc,comp.org.eff.talk
Subject: Re: Stupid Licenses (YUCK!)
Date: 29 Dec 92 00:29:45 GMT
Article-I.D.: qiclab.1992Dec29.002945.4377
Reply-To: Leonard.Erickson@f51.n105.z1.fidonet.org
Organization: SCN Research/Qic Laboratories of Tigard, Oregon.

charlie@umnstat.stat.umn.edu (Charles Geyer) writes:

>In article <1992Dec22.034142.14471@fsl.noaa.gov> bear@kestrel.fsl.noaa.gov
>(Bear Giles) asks:

>> Would you postpone a release with known bugs (documented in a 'here there
>> be dragons' addendum) which would replace a previous, more buggy version?

>Why can't they just provide a release that fixes the old bugs without
>introducing (known) new ones?  Featurality first is the only explanation.

Well, I know of a case where this was tried, but one of the fixes involved
switching from a no longer supported (and *buggy*) comm library to a new
library that turned out to be buggier than expected. While waiting for
the fixes, the programmers decided to add a few of the "easy" features
users had been requesting. Which (of course) lead to a few new bugs.

-- 
Leonard Erickson		      leonard@qiclab.scn.rain.com
CIS: [70465,203]			 70465.203@compuserve.com
FIDO:   1:105/51	 Leonard.Erickson@f51.n105.z1.fidonet.org
(The CIS & Fido addresses are preferred)
From: kludge@grissom.larc.nasa.gov (Scott Dorsey)
Newsgroups: comp.security.misc
Subject: Re: Future OS virus immunity.
Date: 31 Dec 1992 14:31:12 GMT
Organization: NASA Langley Research Center and Reptile Farm
NNTP-Posting-Host: grissom.larc.nasa.gov

In article <eronald.725752239@ruble> eronald@fml.tuwien.ac.at (Edmund Ronald) writes:
>
> I am a Paris based computer-interest writer, and I need info about current
>trends on making operating systems virus-resistent. Could people tell me 
>what the lines of research are?

Viruses aren't a real problem in any system that has memory protection and
any way to prevent users from directly writing into system space.  In such
a system, a user would be able to destroy his own area, but wouldn't be
able to touch the OS.

There was a lot of research in the sixties on memory protection systems,
and most modern OS designs use some degree of per-process protection of
core and disk.

Unfortunately the two major microcomputer operating systems are still in
the early 60's level of technology.  This is a marketing problem, not
a technological one.  If people refused to use junk like MS-DOS and Mac OS,
viruses would be almost nonexistant.
--scott
Xref: sparky comp.security.misc:2394 comp.org.eff.talk:8197