Some input for ssphwg issues

[[e-mail] (Dewey Henize)]

I'm not completely clear yet as to the functioning of  the  group
as well, but perhaps this will be useful to others at least.

Backround:

Execucom Systems Corp (ESC) is a small to mid sized software com-
pany.  We make a product that is primarily used in the upper lev-
els of management at our clients, and target at a wide  range  of
vendor  boxes,  with  a  lot of our sales still in the IBM world.
Inhouse we use a Sequent S81 as our central  machine,  with  Decs
and  Suns  accounting  for  the majority of our workstations.  We
have no Internet connect, but do a lot of work with UUCP and have
an  X.25  link  used  to  provide dialup access for remote client
classes and sales demos.

The best way to describe our expertise is 'self-taught'.   As  an
isolated  site,  we  have  tried  to  get  to as many classes and
conferences as we can, but the range of what's available in  Aus-
tin Tx is, to put it diplomatically, quite limited.

Our DP services staff (which includes all functions - network ad-
min,  systems admin, backup, restore, etc.) and our R&D group are
relatively well educated in Unix, but the overall  level  of  our
user  base  is  weak to pathetic.  However, until recently, there
was no recognition by upper management that this was  a  problem.
Unfortunately, this lack of interest applied equally to issues of
security.

Situation:

A couple months ago, we were electronically  vandalized.   [Note,
I'm  not  using  the overworked term 'hacked'.  By no stretch can
the individual(s) who broke in here deserve that term  -  it  was
obvious  no  great knowledge of what they were doing was present,
simply a list of known generic methods to try to get root  access
and  to preserve avenues for subsequent later attempts.]  The en-
try was through the X.25 network interface, but outside  of  that
detail,  the  methods used were the same as has been discussed at
length in many of the recent security group announcements.

Luckily the vandal was either incompetent or  lazy  -  he  hadn't
bothered  to  find  out  a few standard details about some of the
files he wanted to alter to hide his tracks, and in  the  process
brought the system down before too much major damage could occur.

Result:

Security is now recognized as an issue.  DP personnel have  spent
hundreds  of  hours  educating  our user base in just what was at
risk and in the process have (for the most part) gotten  them  to
realize  that  a  basic understanding of the system(s) as a whole
are both capable of much more than they dreamed and that they are
also vulnerable.

Changes to the interconnections between our  machines  have  been
implemented.   Where  before almost any user on any machine could
do anything anywhere, we now have much more limited access.   Re-
mote  root access is limited only to those machines where a regu-
lar need is shown.  The majority of our  non-technical  personnel
are  limited  to  using the central machine, since there's really
nothing on the individual workstations they need to access.

Users are now made responsible  for  their  passwords  being  are
checked  after being changed by some simple programs to make sure
they aren't easily hackable.  For example, it better not  be  any
part of the users name or GCOS field, it mustn't be a word in the
various online dictionaries, etc.

We have (finally) been allowed to implement most of the  security
fixes  we  have  known needed implementation for a long time.  We
are also much more agressive toward our  vendors.   As  a  binary
license  site  there  are  a great many holes that WE cannot fix.
Our attitude is, and we have enlisted our corporate  attorney  in
this,  that  if  a vendor wants to sell us a box and an operating
system then we expect them to remain current in the field and  to
provide  any  patches  needed  to  solve generally known security
problems.

Why tell you all this:

All the above is to let you know where we were and where  we  are
now.   Here's how we were able to get as far as we have, though -
hopefully some of you can benefit from our experience.

First, you (the systems administrators) have to become  knowledg-
able  in what kinds of security issues there are for your type of
site.  What do you have that's worth  protecting  -  CPU  cycles,
data  files, accounting data bases, proprietary source, whatever.
Talk to folks with a stake in keeping these  resources  available
and  yet  secure.   Find out what impact it would have on some of
these other groups if they were deprived of these  resources,  or
if they weren't able to depend on their data being valid.

Learn what you CAN do to make your  site  safer.   What  standard
brand  software  are  you  running  that opens you up to vandals.
Determine if you need to run all of it or whether some of it came
with  some  standard  setups and doesn't really apply to you.  If
you can get rid of something with big holes with  a  minimal  im-
pact,  consider  doing  so.   Replace  what  you  can with better
software, whether from the vendor or from public domain  or  from
commercial sources.

Start lining up support from outside your group to  back  you  in
implementing  your own procedures.  The accounting folks, for ex-
ample, will be much more likely to support you if you put togeth-
er  an impact analysis of what would happen to their operation if
all data were suspect and had to be reentered  before  continuing
with  day  to day operations.  Production software groups seem to
be much more interested if you point out that vandals could  ran-
domly  change  code  thought  to  be  already tested and secured,
perhaps causing delays in release.

Start codifying (if you haven't) what you're  trying  to  do  and
what  level  of  support you expect your users to give you in ex-
change for what you are trying to give them.  Your user  base  is
where  the  holes are worst, and where they are most likely to be
plugable.  Don't alienate them by imposing a  lot  of  rules  and
restrictions without making solid efforts to communicate just why
the measures are needed.

Summary:

I don't know if this helps anyone or not.  I've  only  hit  on  a
very  few of the specifics we actually do.  What I've tried to do
is to share with you what we have tried to accomplish and some of
the  ways we have approached these goals.  I hope there will be a
lot more detailed reports from some of you that have fought  some
of these battles on your own turf, and that I can add things that
we've found.

Security policies are, to me, one of the biggest black  holes  in
systems  and network administration.  Outside of the super agres-
sive systems where all passwords are  assigned  gobbletygook  and
major  paperwork  is  implied by ANY access, there's not a lot in
the field that I'm aware of to refer to.  This makes it very hard
sometimes to start up new procedures.  For us, for example, there
was a lot of attitude in our management that we were  just  small
fry  anyhow and no one would want to bother us, so why go through
hassles making things slightly  less  convienent.   Ignorance  of
what  vandals  could  do also made it very difficult to implement
new, less open, procedures.

The image presented by the media and  the  popular  press,  where
these  electronic  intruders are presented as some sort of misun-
derstood genius underground, works directly against getting  sup-
port  for  security  measures.  As a system administrator, and an
active member of the BBS community as well, I'm aware there are a
few  really  smart  and only inquisitive folks out there who just
want to look around.  But, I also know that most of  them  either
purposely or inadvertantly share the techniques with lots of oth-
ers who are at best much less careful, and at worst actively des-
tructive.  Educating your user base that there are both kinds out
there and that your system is a target is, I believe, a  critical
step  in  getting the permission and authority you need to secure
your system.

Dewey Henize

-- 
Dewey Henize                                       Execucom Systems Corp
[phone]                                     108 Wild Basin Rd
Network Administrator                              Austin, Tx 78746
...{cs.utexas.edu | uunet}!execu!dewey    or       [e-mail]