THE BIGGEST COMPUTER SECURITY THREAT
                      by Vladimir Volokh, VESOFT
        Presented at INTEREX Conference 1990, Boston, MA, USA
                    Published by VENEWS, #6, 1991.


The  problem  of  computer  security  was  definitely not  invented by
software vendors -- just read the newspapers every day.

Computer crimes come in different flavors:

* simply reading sensitive data (prices, customer lists, etc.)

* modification of data (payroll rates, shipping information)

* sabotage (viruses, time bombs, intentional system crashes)

* software theft

* unauthorized computer use

* defense-related crimes

* and more...

Security-minded  authors have written many  books, as well as articles
in  HP-related  publications,  on  this  subject; we  at VESOFT became
involved  in  the  HP3000  security  industry  in  its  very  infancy,
presenting  computer  security  papers  at  HP  conferences  in Berlin
(1981),  Copenhagen (1982), Anaheim (1984), and, most recently, at the
INTEREX security seminar in 1989.

And  yet  not  every  HP3000 computer is secure!  The word SECURITY is
misleadingly simple, simple enough to make many people think that they
have  adequate system security without  fully thinking out what HP3000
security really entails.

The  issue  of  computer  security  is  actually  very  complex  -- it
involves:

* physical security (guards, dogs, locks)

* system set-up (accounts, groups, users, capabilities, access, etc.)

* LOGON security

* file system security (why does MPE have a :RELEASE command?)

* IMAGE security (have you EVER changed your database password?)

* application security (who is allowed to print checks?)

* data encryption (fields, files)

*  LOGOFF security (can people just  walk up to an unattended terminal
  and use it?)

* batch access

* back-up and disaster recovery

* and more... much more...

System  security  is  every  bit  as much a primary  concern of any DP
department as the actual applications running on the machine.


SYSTEM SET-UP

Look at your accounting structure first:

* What accounts do you have (check it by using :REPORT X.@)?

* What groups (use :REPORT @.@)?

* What users (:LISTUSER @.@)?

* Which capabilities do each of them have (SM, OP, PM)?

* What kind of access (Read, Write... -- for ANY, AC, GU...)?

* Are all of these entities passworded, or only some of them?

* Are some of the existing passwords too short or too obvious?

* How often are they changed (if at all)?

* How many various levels of UDCs are set on your system?

* And if you rely on them, how easy is it to bypass them?


LOGON SECURITY

Logon  to the HP seems to be quite secure with ACCOUNT, GROUP and USER
passwords. Or is it?  Look carefully:

* MPE error messages at logon time are too "friendly"

* Passwords are readable combinations of up to 8 ASCII characters

*  They are either easy to guess or difficult to remember -- and users
  write them down (sometimes even stick them to the terminal)

* They are often shared or simply disclosed

* Seldom changed

*  If  users  use the session name  (:HELLO MARY,MGR.PAYROLL), it only
  looks  better -- the session name isn't enforceable and the password
  is assigned to user (MGR) anyway

*  Yes, the MPE password is assigned,  so account manager is the first
  suspect (and all SM users too)

* Is it easy to enforce shifts (time restrictions on logon)?

* Can payroll be run in the computer room (from LDEV 20)?

* Or can it be done on the weekend?

* Can end-users ever see ":"? What can they do then?

*  What is better: to forbid most MPE commands via "clever" UDCs or to
  let users execute only some commands and subsystems?

*  And if you have a logon  UDC which brings them into an application,
  how  about  some  other applications (e.g.  HPMAIL), some utilities?
  Should users constantly change their logon ID?


REMOTE ACCESS

Remote access to the computer is common nowdays: dial-up, DS, NS...

*  Who  knows  your  dial-up telephone number?  Your former employees,
  current employees, telephone company workers, HP SEs...

*  Simple question: what to do if a person leaves the company? (Change
  all  passwords  on  the  system, unplug dial-up  forever, request to
  change your dial-up number...)

*  We have a horror story to tell you: one of our customers did change
  their   dial-up   number,   but...   the   telephone   company   set
  call-forwarding  onto  it  (you know the message  -- "The number has
  been changed, the new number is...")

*  And  if  there  are two or more  computers linked together, can any
  programmer access the production HP/960 from the development HP/42?


LOGOFF SECURITY

Logoff  is also a problem: you should realize that unattended sessions
constitute  a major threat to system  security.  The more sessions you
have (it can be hundreds on XL) the less control you have.

*  Remember  that an unattended terminal is  a convenient way for some
  people to use your system without logging-on.

*  Also,  if  the session is left on  after hours and keeps some files
  open these files might not be backed up.


BATCH SECURITY

Batch security is as important as on-line, but...

* MPE requires passwords to be included in job cards, so a typical job
  card looks like this :JOB FULLDUMP,MANAGER/SECRET.SYS/QWERTY

*  This  makes  passwords  easy  to  read  by unauthorized  people and
  difficult  to  change  on a regular basis  by people responsible for
  system security (it might be you)

*  There  are  some  other  important  things  built  into  streams --
  lockwords, database and/or application passwords, etc.

*  The  situation  is  somewhat  better if all of  your streams are in
  groups with X:ANY,R:GU access -- but try to verify this


IMAGE SECURITY

IMAGE  security had better be good  -- that's where our most important
data usually is.  However

* Passwords (up to 6 of them) create the appearance of good protection
  of the base, sets, and entries

*  But...  these  passwords are often built  into sources -- intrinsic
  DBOPEN  requires this; source code is compiled and guess what? IMAGE
  passwords  are never changed!  The situation is so bad and continues
  for so long, that HP users seldom recognize this kind of danger.

*  It's  even  worse  when  using  some  application  packages  -- all
  customers  of this package have the  same password.  Would you buy a
  car with the same key for everybody else who buys the same car?

*  Some  system managers sense something wrong  in this area and set a
  lockword  on QUERY.  It's better than  nothing, but what about other
  database retrieval tools or custom written programs?


FILE SYSTEM SECURITY

File  system  security  in  general  is  very important.   A couple of
questions come to mind:

* How many files on your HP are released?

* Even worse -- are these files in PM groups?

* And how do you :SECURE hundreds of them? Are you the "creator"?

* Which files were accessed on your HP over the weekend?

* How many programs, and which ones, have PM capability?

*  Is it possible to :FCOPY the  object code of your programs in ;CHAR
mode and see all the 'built-ins'?

*  Do you like the recent  ACD (Access Control Definition) enhancement
  for  MPE/V  file system, which, in  short, links particular users to
  the file?

* If so, before using ACDs, think about selection of these files later
  --  they  will be as invisible as  :RELEASEd files; think also about
  setting  ACDs  for  groups of files, saving  ACDs after editing text
  files, etc.

Having said all of the above let's ask ourselves:

What is the biggest computer security threat?

It  seems  that  the  problem  lies in the wrong  approach to the risk
management  on  the part of DP personnel.   As long as system managers
continue  to count on users' ignorance,  on end-users being "good", on
having only one dial-up line (yes, we've heard this one too) and such,
company assets -- and some people's resumes -- will be in danger.

Go to Adager's index of technical papers