home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 1 / HACKER1.ISO / network / nia24 < prev    next >
Text File  |  1992-09-26  |  22KB  |  433 lines

  1.  ZDDDDDDDDDDDDDDDDDD? IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM; ZDDDDDDDDDDDDDDDDDD?
  2.  3   Founded By:    3 :  Network Information Access   : 3 Mother Earth BBS 3
  3.  3 Guardian Of Time 3D:            17APR90            :D3  NUP:> DECnet    3
  4.  3   Judge Dredd    3 :          Judge Dredd          : 3Text File Archives3
  5.  @DDDDDDDDBDDDDDDDDDY :            File 24            : @DDDDDDDDDBDDDDDDDDY
  6.           3           HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<           3
  7.           3           IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM;           3
  8.           @DDDDDDDDDDD6 Computer Viruses & Threats II GDDDDDDDDDDDY
  9.                       HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<
  10.  
  11. $_Virus Prevention in General
  12.  
  13.  
  14.    To provide general  protection from attacks by  computer viruses,
  15.    unauthorized users, and related threats,  users and managers need
  16.    to eliminate or reduce vulnerabilities.  A general summary of the
  17.    vulnerabilities that  computer viruses  and  related threats  are
  18.    most likely to exploit is as follows:
  19.  
  20.       - lack of user  awareness - users  copy and share  infected
  21.         software, fail to detect signs of virus activity,  do not
  22.         understand proper security techniques
  23.  
  24.       - absence  of or  inadequate security  controls -  personal
  25.         computers generally  lack software and  hardware security
  26.         mechanisms that help  to prevent and detect  unauthorized
  27.         use,  existing   controls  on   multi-user  systems   can
  28.         sometimes be surmounted by knowledgeable users
  29.  
  30.       - ineffective  use of  existing  security controls  - using
  31.         easily guessed passwords, failing to use access controls,
  32.         granting users more access to resources than necessary
  33.  
  34.       - bugs  and  loopholes  in   system  software  -   enabling
  35.         knowledgeable users to break into systems or exceed their
  36.         authorized privileges
  37.  
  38.       - unauthorized use  - unauthorized  users can  break in  to
  39.         systems,  authorized users can exceed levels of privilege
  40.         and misuse systems
  41.  
  42.       - susceptibility  of  networks  to  misuse  - networks  can
  43.         provide anonymous access to systems,  many are in general
  44.         only as secure as the systems which use them
  45.  
  46.    As can be seen from this  summary, virus prevention requires that
  47.    many  diverse  vulnerabilities   be  addressed.    Some   of  the
  48.    vulnerabilities  can  be  improved  upon significantly,  such  as
  49.    security controls that can be added or improved, while others are
  50.    somewhat inherent in computing, such as  the risk that users will
  51.    not use  security controls  or follow  policies, or  the risk  of
  52.    unauthorized use of computers and networks.  Thus,  it may not be
  53.    possible  to  completely  protect  systems  from  all  virus-like
  54.    attacks.   However, to  attain a realistic  degree of protection,
  55.    all areas of vulnerability must be addressed; improving upon some
  56.    areas at the expense of others will still leave significant holes
  57.    in security.
  58.  
  59.  
  60.    To  adequately  address all  areas  of vulnerability,  the active
  61.    involvement  of individual  users, the management  structure, and
  62.    the  organization  in a  virus  prevention program  is essential.
  63.    Such a program, whether formal or informal, depends on the mutual
  64.    cooperation of the  three groups to identify  vulnerabilities, to
  65.    take steps to correct them, and to monitor the results.
  66.  
  67.    A virus prevention program must be initially based upon effective
  68.    system   computer  administration   that   restricts  access   to
  69.    authorized  users,   ensures  that  hardware  and   software  are
  70.    regularly monitored and maintained, makes  backups regularly, and
  71.    maintains contingency  procedures for potential  problems.  Sites
  72.    that do not maintain a basic computer administration program need
  73.    to put  one into place, regardless of their  size or the types of
  74.    computers used.  Many system vendors supply system administration
  75.    manuals that describe the aspects of a basic program.
  76.  
  77.    Once a basic  administration program is in  place, management and
  78.    users need  to incorporate  virus prevention  measures that  will
  79.    help to deter attacks by viruses and related threats, detect when
  80.    they occur, contain the attacks to limit damage, and recover in a
  81.    reasonable amount of  time without loss  of data.  To  accomplish
  82.    these aims, attention needs to be focused on the following areas:
  83.  
  84.       - educating users  about malicious software in general, the
  85.         risks  that  it  poses,  how  to  use  control  measures,
  86.         policies, and  procedures to  protect themselves  and the
  87.         organization
  88.  
  89.       - software management policies  and procedures that address
  90.         public-domain software, and  the use  and maintenance  of
  91.         software in general
  92.  
  93.       - use of technical controls that  help to prevent and deter
  94.         attacks by malicious software and unauthorized users
  95.  
  96.       - monitoring of user and software  activity to detect signs
  97.         of attacks, to  detect policy violations, and  to monitor
  98.         the overall  effectiveness of  policies, procedures,  and
  99.         controls
  100.  
  101.       - contingency policies  and procedures  for containing  and
  102.         recovering from attacks
  103.  
  104.    General  guidance  in each  of these  areas  is explained  in the
  105.    following sections.
  106.  
  107.  
  108. $_Education
  109.  
  110.  
  111.    Education is  one of  the primary  methods by  which systems  and
  112.    organizations can  achieve greater  protection from  incidents of
  113.    malicious software  and unauthorized  use.   In situations  where
  114.    technical controls do not provide complete protection (i.e., most
  115.    computers),  it  is ultimately  people  and their  willingness to
  116.    adhere to security  policies that will determine  whether systems
  117.    and organizations  are protected.   By educating users  about the
  118.    general  nature  of  computer  viruses  and related  threats,  an
  119.    organization can improve  its ability  to deter, detect,  contain
  120.  
  121.    Users should be educated about the following:
  122.  
  123.       - how malicious software  operates, methods by which  it is
  124.         planted  and  spread,  the  vulnerabilities exploited  by
  125.         malicious software and unauthorized users
  126.  
  127.       - general security policies  and procedures and how  to use
  128.         them
  129.  
  130.       - the policies to follow regarding the backup, storage, and
  131.         use of  software, especially  public-domain software  and
  132.         shareware
  133.  
  134.       - how  to use  the technical  controls they  have at  their
  135.         disposal to protect themselves
  136.  
  137.       - how to monitor their systems and software to detect signs
  138.         of abnormal activity, what  to do or whom to  contact for
  139.         more information
  140.  
  141.       - contingency procedures for containing and recovering from
  142.         potential incidents
  143.  
  144.    User education,  while perhaps  expensive in  terms  of time  and
  145.    resources required,  is ultimately a  cost-effective measure  for
  146.    protecting  against   incidents   of   malicious   software   and
  147.    unauthorized  use.  Users  who  are  better acquainted  with  the
  148.    destructive potential of  malicious software  and the methods  by
  149.    which it  can attack  systems may  in  turn be  prompted to  take
  150.    measures to protect themselves.  The purpose of security policies
  151.    and procedures will be more clear, thus users may be more willing
  152.    to actively use them.  By  educating users how to detect abnormal
  153.    system activity  and the resultant steps to follow for containing
  154.    and recovering from potential  incidents, organizations will save
  155.    money and time if and when actual incidents occur.
  156.  
  157. $_Software Management
  158.  
  159.  
  160.    As shown by  examples in File 1,  one of the prime  methods by
  161.    which malicious software  is initially copied onto  systems is by
  162.    unsuspecting users.   When users  download programs from  sources
  163.    such  as  software  bulletin  boards,  or public  directories  on
  164.    systems or network servers, or in  general use and share software
  165.    that has  not been obtained from a reputable source, users are in
  166.    danger of  spreading malicious software.   To prevent  users from
  167.    potentially spreading malicious software, managers need to
  168.  
  169.       - ensure  that  users understand  the  nature of  malicious
  170.         software,  how it is generally  spread, and the technical
  171.         controls to use to protect themselves
  172.  
  173.       - develop policies for  the downloading and use  of public-
  174.         domain and shareware software
  175.  
  176.       - create  some mechanism for validating such software prior
  177.         to allowing users to copy and use it
  178.  
  179.       - minimize the exchange  of executable  software within  an
  180.         organization as much as possible
  181.  
  182.       - do not create  software repositories on LAN servers or in
  183.         multi-user system directories  unless technical  controls
  184.         exist  to   prevent  users   from  freely   uploading  or
  185.         downloading the software
  186.  
  187.    The  role  of  education  is  important,  as  users  who  do  not
  188.    understand  the risks  yet who  are  asked to  follow necessarily
  189.    restrictive policies may share and  copy software anyway.   Where
  190.    technical controls  cannot prevent  placing new  software onto  a
  191.    system, users are  then primarily responsible for the  success or
  192.    failure of whatever policies are developed.
  193.  
  194.    A policy  that  prohibits any  copying  or use  of  public-domain
  195.    software  may  be  overly  restrictive,  as  some  public  domain
  196.    programs have proved  to be  useful.  A  less restrictive  policy
  197.    would  allow some  copying, however  a  user might  first require
  198.    permission from the appropriate manager.  A special system should
  199.    be used  from which  to perform  the copy  and then  to test  the
  200.    software.  This type of system, called an isolated system, should
  201.    be configured so that there is no risk of spreading a potentially
  202.    malicious program to other areas of  an organization.  The system
  203.    should  not  be  used  by  other  users, should  not  connect  to
  204.    networks, and should not contain any  valuable data.  An isolated
  205.    system should also be used  to test internally developed software
  206.    and updates to vendor software.
  207.  
  208.    Other policies for managing vendor  software should be developed.
  209.    These  policies  should   control  how  and  where   software  is
  210.    purchased, and should govern where the software  is installed and
  211.    how it is to be used.  The following policies and  procedures are
  212.    suggested:
  213.  
  214.       - purchase vendor software only from reputable sources
  215.  
  216.       - maintain the software properly and update it as necessary
  217.  
  218.       - don't use pirated software, as it may have been modified
  219.  
  220.       - keep  records  of  where  software is  installed  readily
  221.         available for contingency purposes
  222.  
  223.       - ensure that vendors can be  contacted quickly if problems
  224.         occur
  225.  
  226.       - store the original  disks or tapes  from the vendor in  a
  227.         secure location
  228.  
  229.  
  230. $_Technical Controls
  231.  
  232.    Technical  controls  are  the  mechanisms  used  to  protect  the
  233.    security and integrity of  systems and associated data.   The use
  234.    of technical controls can help  to prevent occurrences of viruses
  235.    and related threats by deterring them or making it more difficult
  236.    for them  to  gain access  to  systems  and data.    Examples  of
  237.    technical controls include user authentication mechanisms such as
  238.    passwords, mechanisms which provide selective levels of access to
  239.    files and directories  (read-only, no  access, access to  certain
  240.    users,  etc.),  and  write-protection  mechanisms  on  tapes  and
  241.    diskettes.
  242.  
  243.  
  244.    The different types of technical controls and the degree to which
  245.    they  can provide protection and deterrence varies from system to
  246.    system, thus the use  of specific types of controls  is discussed
  247.    in the following files.  However,  the following general points are
  248.    important to note:
  249.  
  250.       - technical  controls  should  be  used  as   available  to
  251.         restrict system access to authorized users only
  252.  
  253.       - in the multi-user environment, technical controls  should
  254.         be  used  to  limit  users'  privileges  to  the  minimum
  255.         practical level; they should work  automatically and need
  256.         not be initiated by users
  257.  
  258.       - users and system managers must be  educated as to how and
  259.         when to use technical controls
  260.  
  261.       - where  technical controls are weak or non-existent (i.e.,
  262.         personal  computers), they  should  be supplemented  with
  263.         alternative   physical   controls   or   add-on   control
  264.         mechanisms
  265.  
  266.    Managers need to determine which technical controls are available
  267.    on their systems,  and then the  degree to which  they should  be
  268.    used and whether  additional add-on controls are  necessary.  One
  269.    way  to  answer  these  questions  is  to  first  categorize  the
  270.    different classes of data being processed by a system or systems,
  271.    and then to  rank the  categories according to  criteria such  as
  272.    sensitivity to the  organization and vulnerability of  the system
  273.    to attack.  The rankings should then help determine the degree to
  274.    which  the  controls  should be  applied  and  whether additional
  275.    controls are  necessary.   Ideally, those systems  with the  most
  276.    effective controls should be used  to process the most  sensitive
  277.    data, and vice-versa.   As an example, a personal  computer which
  278.    processes  sensitive employee  information should  require add-on
  279.    user authentication mechanisms, whereas  a personal computer used
  280.    for general word processing may not need additional controls.
  281.  
  282.  
  283.    It is important to note that  technical controls do not generally
  284.    provide complete protection against viruses  and related threats.
  285.    They may be cracked by determined  users who are knowledgeable of
  286.    hidden  bugs and weaknesses,  and they may  be surmounted through
  287.    the use of Trojan horse programs, as shown by examples in File
  288.    1.  An  inherent weakness  in technical controls  is that,  while
  289.    deterring users and  software from objects  to which they do  not
  290.    have  access,  they may  be  totally ineffective  against attacks
  291.    which target objects that are accessible.  For example, technical
  292.    controls may not prevent an authorized user from destroying files
  293.    to which the user has authorized  access.  Most importantly, when
  294.    technical controls  are not  used properly, they  may increase  a
  295.    system's  degree of vulnerability.   It is  generally agreed that
  296.    fully effective technical  controls will not be  widely available
  297.    for some time.   Because of the immediate nature of  the computer
  298.    virus threat,  technical controls  must be  supplemented by  less
  299.    technically-oriented control  measures such as  described in this
  300.    chapter.
  301.  
  302. $_General Monitoring
  303.  
  304.    An  important aspect of  computer viruses and  related threats is
  305.    that they  potentially can cause  extensive damage within  a very
  306.    small amount of time, such as minutes or seconds.  Through proper
  307.    monitoring of software, system activity,  and in some cases  user
  308.    activity,  managers  can increase  their  chances that  they will
  309.    detect   early  signs  of  malicious  software  and  unauthorized
  310.    activity.  Once the presence is  noted or suspected, managers can
  311.    then  use  contingency  procedures to  contain  the  activity and
  312.    recover  from whatever  damage has  been  caused.   An additional
  313.    benefit of  general monitoring is that  over time, it can  aid in
  314.    determining  the  necessary  level  or   degree  of  security  by
  315.    indicating  whether security  policies, procedures,  and controls
  316.    are working as planned.
  317.  
  318.    Monitoring  is  a  combination  of  continual system  and  system
  319.    management activity.   Its effectiveness  depends on  cooperation
  320.    between management and users.   The following items are necessary
  321.    for effective monitoring:
  322.  
  323.       - user  education  -  users must  know,  specific  to their
  324.         computing  environment,  what   constitutes  normal   and
  325.         abnormal system activity and whom  to contact for further
  326.         information - this  is especially important for  users of
  327.         personal  computers,  which   generally  lack   automated
  328.         methods for monitoring
  329.  
  330.       - automated system  monitoring tools - generally  on multi-
  331.         user systems, to  automate logging or accounting  of user
  332.         and  software  accesses  to accounts,  files,  and  other
  333.         system objects  - can sometimes  be tuned to  record only
  334.         certain types of accesses such as "illegal" accesses
  335.  
  336.       - anti-viral software  - generally  on personal  computers,
  337.         these tools alert users of certain types of system access
  338.         that are indicative of "typical" malicious software
  339.  
  340.       - system-sweep programs  - programs to  automatically check
  341.         files for changes in size, date, or content
  342.  
  343.       - network  monitoring  tools -  as  with system  monitoring
  344.         tools, to record network accesses or attempts to access
  345.  
  346.    The statistics gained  from monitoring activities should  be used
  347.    as input for periodic reviews of  security programs.  The reviews
  348.    should  evaluate the effectiveness  of general system management,
  349.    and associated security policies, procedures,  and controls.  The
  350.    statistics will indicate  the need for  changes and will help  to
  351.    fine tune the program so that security is distributed to where it
  352.    is most necessary.   The reviews  should also incorporate  users'
  353.    suggestions,  and  to  ensure  that  the program  is  not  overly
  354.    restrictive, their criticisms.
  355.  
  356. $_Contingency Planning
  357.  
  358.  
  359.    The  purpose  of  contingency planning  with  regard  to computer
  360.    viruses and related threats is to be able to  contain and recover
  361.    completely from  actual attacks.  In many  ways, effective system
  362.    management  that  includes  user  education,  use   of  technical
  363.    controls,  software management,  and monitoring activities,  is a
  364.    form  of  contingency  planning, generally  because  a  well-run,
  365.    organized  system  or facility  is better  able to  withstand the
  366.    disruption that could  result from a  computer virus attack.   In
  367.    addition to effective system management activities, managers need
  368.    to consider  other contingency procedures that  specifically take
  369.    into account the nature of computer viruses and related threats.
  370.  
  371.    Possibly  the  most   important  contingency  planning   activity
  372.    involves the use of backups.  The ability to recover from a virus
  373.    attack depends upon maintaining regular,  frequent backups of all
  374.    system data.   Each backup should be  checked to ensure  that the
  375.    backup media has not  been corrupted.  Backup media  could easily
  376.    be corrupted because of defects, because the backup procedure was
  377.    incorrect, or perhaps because the backup software itself has been
  378.    attacked and modified to corrupt backups as they are made.
  379.  
  380.    Contingency procedures for  restoring from backups after  a virus
  381.    attack  are equally  important.   Backups may  contain  copies of
  382.    malicious  software  that   have  been  hiding  in   the  system.
  383.    Restoring  the  malicious software  to  a  system  that has  been
  384.    attacked could  cause a recurrence of the problem.  To avoid this
  385.    possibility, software should  be restored only from  its original
  386.    media:   the tapes or diskettes from the  vendor.  In some cases,
  387.    this may  involve reconfiguring the software,  therefore managers
  388.    must maintain copies of configuration  information for system and
  389.    application software.   Because data is not  directly executable,
  390.    it  can be restored from routine backups.  However, data that has
  391.    been  damaged  may need  to be  restored  manually or  from older
  392.    backups.    Command files  such  as  batch  procedures and  files
  393.    executed  when  systems  boot  or  when  user log  on  should  be
  394.    inspected to ensure that they have  not been damaged or modified.
  395.    Thus,  managers  will  need  to  retain  successive  versions  of
  396.    backups, and search through them when restoring  damaged data and
  397.    command files.
  398.  
  399.    Other contingency procedures for containing virus attacks need to
  400.    be developed.  The following are suggested; they are discussed in
  401.    more detail in following files:
  402.  
  403.  
  404.       - ensure that accurate  records are  kept of each  system's
  405.         configuration,  including  the  system's   location,  the
  406.         software  it   runs,  the  system's  network   and  modem
  407.         connections,  and  the name  of  the system's  manager or
  408.         responsible individual
  409.  
  410.       - create a  group  of  skilled users  to  deal  with  virus
  411.         incidents and ensure that users  can quickly contact this
  412.         group if they suspect signs of viral activity
  413.  
  414.       - maintain a security  distribution list at each  site with
  415.         appropriate telephone numbers of managers to contact when
  416.         problems occur
  417.  
  418.       - isolate critical systems from  networks and other sources
  419.         of infection
  420.  
  421.       - place outside  network connections  on  systems with  the
  422.         best  protections,  use  central  gateways to  facilitate
  423.         rapid disconnects
  424.  
  425. -JUDGE DREDD/NIA
  426.  
  427. [OTHER WORLD BBS]
  428.  
  429.  
  430.  
  431.  
  432. Downloaded From P-80 International Information Systems 304-744-2253 12yrs+
  433.