SJARVIS.OCT

NO SECURITY BREACHES YET?  
OR JUST NONE THAT YOU'RE AWARE OF?
by SIMON JARVIS

Simon Jarvis has been involved in the computer industry since
1976, working with IBM/370 and XA machines in operations,
application programming and systems programming.  For the last
four years, he has worked for third-party software companies and
is currently the Security Product Manager at C & K Software Ltd.,
the developer of NC-PASS.
Network Security
VTAM networks have expanded at a staggering rate in recent years
and access to them has been extended by use of dial-up lines,
X.25 lines and open networks to give access to home workers,
other networks and people outside the direct control of the
company that owns the network, such as insurance brokers and
credit brokers.  This openness poses two major problems:  first,
access to the system should be simple and helpful to ensure that
non-computer literate users can easily use the service, and
second, access to the system must be secure to ensure that
unauthorized users cannot gain entry.  These two statements
appear to be mutually exclusive -- how can something that is easy
to
access by legitimate users, be secured from access by "hackers"? 
I believe that both these targets can be achieved and I will
explain how this can be accomplished by posing the problems and
giving possible answers using today's technology.  
Network Front-Ends
A number of "Network front-end" products have been available for
some time now.  They provide a single point of entry to a
network, usually with a logon panel and a menu panel and they run
as VTAM applications.  Users enter their userid and password on
the logon panel; they are then shown the menu of applications
they are allowed to use, and they select one and are connected to
it with their userid and password being passed as CINIT data. 
Terminals will be LOGAPPL'd to the front-end and when the session
with an application ends, they will be re-acquired by the front-
end.  These systems vary in sophistication, but normally provide
formatted screens with fields for userid and password, help
information, some kind of messaging and information about the
system they are logged onto.  
Session managers are sophisticated network front-ends that allow
connection to multiple VTAM applications simultaneously and can
use scripted commands to communicate with the applications.  
All these facilities are great for providing a "user-friendly"
front end to the network, but they also give a lot of clues to a
potential "hacker."  The "hacker" will be able to see what system
has been connected, get help panels displayed, receive helpful
error messages from the system that checks the password and
possibly get a userid from a broadcast message.  
An alternative to this approach is to provide a blank panel with
no help and no messages.  Unfortunately this will not only deter
hackers, but also legitimate users of the system.  This
highlights a problem -- how do you provide a "user friendly"
network front-end that is not "hacker-friendly"? 
As stated previously, all terminals connected to a system will be
"LOGAPPL'd" to the front-end, and the front-end will re-acquire
the terminal when it disconnects from an application.  However,
if a terminal is connected to another network node, which may not
be under the control of a front-end, a user will be able to
bypass the "front-end" by entering a LOGON APPLID(xxxx) command
and going straight to the application.  
This raises another problem -- how do you make your network
"open" and still control access?  VTAM provides a basis for the
answer to this, the authorization exit, which is invoked when a
terminal (or virtual terminal in the case of session managers)
attempts connection to an application.  This exit may allow or
reject the session.  If the network front-end has some way to
communicate with the exit, it can identify connections that have
been authenticated as valid.  Any attempts to connect from
outside the system to a secure application by any non-authorized
route, e.g., LOGAPPL command, or an operator VARY, will be
rejected and reported by the exit.  
Hacking
The term "hacker" conjures up a picture of 14-year-old hunched
over a huge array of hardware having his home computer dial
unlisted phone numbers with a "War Games" program until it
receives the ear splitting shriek of a modem.  This type of
hacker only represents a very small proportion of the overall
problem; by far the highest number of known or admitted "attacks"
come from within the company.  In a recent survey, 25 percent of
computer professionals admitted to hacking a system, 87 percent
of these people were never found out.  
It is impossible to estimate the number of people involved in
hacking, nor the amounts of money involved.  Major companies are
unwilling to admit to known cases of
infiltration and even more unwilling to disclose the  amounts of
money which it has cost them, whether it is through fraud or
through corruption of data.  It is, however, reasonable to assume
that a lot of hacking goes undetected through negligence on the
part of EDP departments or a high-level skill on the part of the
hacker.  In an attempt to categorize the kind of people that come
under the broad heading of "hacker," I will describe the types of
people involved and possible ways of protecting against them.  
The first and most common type of hacker is a person within the
DP department of a company who "borrows" another persons' userid
to do something that the hacker is not authorized to do.  No real
damage is done, unless the hacker makes a mistake. This person
will be very difficult to detect unless a mistake is made and
guilt is addmitted.  
The more common type of hacker from outside the company is the
"War Games" type previously mentioned.  This person does it as a
hobby, probably has very little knowledge of IBM systems and
won't do any damage.  But once this person has found a number
that connects to a computer, that number may be passed on to
friends and other hackers through one of the world-wide bulletin
board systems.  These types of hackers are not very dangerous in
themselves, but they could cause havoc by passing on information. 
Good network connect audit trails should detect this person, by
highlighting dial-up attempts at abnormal times of day or night. 

A more serious hacker within a company would be one who uses a
manager's userid and password to look at personnel records or
electronic mail messages.  The information obtained could be used
for the hacker's own advantage or against someone else.  Audit
trails should help in this situation by showing logons to
sensitive applications from terminals that should not normally be
using them.  
Definitely the most serious internal hacker is malicious,
possibly with a grudge against the company.  At best this type of
hacker could submit 10,000 jobs filling spool volumes and
flooding job queues; at worst the hacker could modify or destroy
databases, release backups, or bring down the system, using other
peoples' userids and passwords.  The only way to stop this person
is to provide a very high level of security.  
The most dangerous person of all is the criminal hacker.  They
will gain access to the system by getting inside information from
employees or ex-employees, or using electronic eavesdropping
techniques to view passwords.  They may be ex-employees who would
have had access to sensitive data or the opportunity to plant
"Trojan horse" programs to inspect passwords.  Once in your
system, they could obtain information to sell to your
competition, disrupt your service for hours or days, or destroy
databases -- in short, they could bankrupt your company.  Only
the very best security will keep this person out.  
As the importance of information held on computers increases, so
does the technical expertise of the potential hacker to the point
where the funds of organized crime or even unfriendly governments
can be utilized in the effort to break through computer security. 

In the light of this view of hackers, my initial problem (how to
provide a "user friendly" network front-end that is not "hacker-
friendly") no longer appears to be a problem.  All the dangerous
hackers already know what userids and passwords to use.  In fact,
the network front-end, by providing a single point of entry into
the system, also provides a point where an audit trail can be
written to show successful and unsuccessful logon attempts.  But
it does highlight the weak link in the system, the password.  
Passwords
The userid/password has become the standard for network,
application and data level security within IBM systems; this
combination is the basis of the security provided by the main
systems available.  The userid identifies a user to the system,
the password verifies that the user is who he says he is -- or
does it?  A password and userid only confirm that the person
attempting access knows these two things, not who the person is. 
By its very nature, a password, in the normal meaning of the
word, is a piece of information that can be written down or
shared between a number of people and is transmitted from 3270
terminals as clear text across lines that may be electronically
eavesdropped to be received by the host in this readable form. 
Passwords need to be easily remembered.  They will be names of
family or friends, phone numbers and commonly used words, all of
which make them easy to guess by hackers with knowledge of their
targets.  Userids normally conform to standards.  Once the
standard is known, any userid can be guessed with minimal inside
information.  This rules out userids as a means of security; they
are purely a means of identification.  This gives us the final
problem -- how to make passwords secure.  There are three golden
rules for good computer security, a combination of two of these
will ensure valid authentication of the user:  something they
know -- a userid/password or userid/PIN (Personal Identification
Number) combination; something about them -- like a fingerprint;
and something they own -- as in a physical key.  
Until recently, only the first of these was practical and usable. 
Recent technology has made the other two areas possible.  
Something You Know
A userid and password.  Although a password alone is insufficient
to provide a high level of security, it is essential as a
component of security.  
Something About You
There are three categories that cover this requirement: 
fingerprint recognition, retina print recognition and written
signature recognition.  On the face of it, these methods seem to
be the most accurate available, but there are a number of
underlying problems.  Accurate fingerprint recognition relies on
the finger being placed in the same position as when it was
digitized.  Signature recognition relies on the signature being
identical each time it is used.  To make these methods usable,
compromises have to be made in the capture and analyses.  This
then creates a situation where, if the analysis is too rough,
false authentication will occur, and, if the analysis is too
fine, valid authentication will be rejected because of slight
fluctuations due to finger position or a shaky hand.  Retina
recognition is far more accurate but requires extremely complex
and costly equipment.  As well as these problems
there is the problem of portability, most devices need to be
attached either directly to a controller or between a terminal
and the controller.  This makes them impossible to supply to
people working "in the field."  
Something You Own
Under this category, I include two types of device.  Although
there are many different implementations of the principles, most
work along similar lines, i.e. they generate a password that is
only usable once, and no more than once.  The principle they
employ involves a pocket calculator-sized device containing an
algorithm which generates an unpredictable pseudo random number
(UPRN).  The network front-end also uses the same algorithm to
verify the UPRN.  Each user owns a device which has been seeded
to produce a unique UPRN, this seed is also held on a database
within the host machine.  When a user attempts connection to the
network, he must enter the UPRN generated by his device into the
mainframe.  The network front-end then compares this with the
expected UPRN and allows or disallows connection.  This type of
security device is usually known as a TOKEN.  
There are two main types of tokens available.  The first is known
as CHALLENGE/RESPONSE -- with this type of token, the user
identifies himself to the mainframe, the mainframe generates a
random challenge and displays it to the user.  The user enters
this challenge into his device and receives a response from it. 
This response is then given to the mainframe where it is compared
with the expected response; if it is valid, connection is
allowed.  
The second type of token is a DYNAMIC PASSWORD.  This kind of
token falls into two broad types:  time-based and previous
password-based.  Time-based devices display a number that changes
every 30 seconds or so.  The number displayed is sent to the
mainframe with a userid and compared against the number expected
for that user at that time.  A correct number will allow access. 
Devices that generate a password from the previous password give
a new number each time they are used derived from a calculation
performed on the last password used.  Both of these types of
devices rely on the mainframe and device staying "in sync."  Both
these types of devices can only be "owned" by one person.  Unlike
a password, they have hardware protection against duplication,
and ensure that people attempting logon to a system are who they
say they are.  Mainframe software which works with these devices
normally provides "duress access" to allow users under threat to
access the system but generate warnings on the system console.  
In my opinion, these devices solve the password problem by
ensuring that a password is valid on the occasion it is used and
never again, while not putting additional pressure on the users
to protect and administer their own passwords.  Any information
gained by word of mouth or electronic eavesdropping is totally
useless.  
With these ideas in mind, it should be easy to create a system
which provides helpful, easy access to the network while ensuring
that it is also secure against unwanted intruders.  Figure 1
summarizes the basics of a secure entry system.  A network front-
end will provide a single point of entry to the system, a menu of
applications which a user is authorized to use and an audit trail
to identify unauthorized access.  Use of the VTAM authorization
exit will ensure that all access to applications has been
authorized by the front-end.  Personal authentication using a
userid/password and a hardware token will provide the "something
you know" and "something you own" that is essential for good
security.  

/*
2496