home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / n_z / nia024.hac < prev    next >
Encoding:
Text File  |  2003-06-11  |  21.2 KB  |  429 lines

  1.  ┌──────────────────┐ ╔═══════════════════════════════╗ ┌──────────────────┐
  2.  │   Founded By:    │ ║  Network Information Access   ║ │ Mother Earth BBS │
  3.  │ Guardian Of Time │─║            17APR90            ║─│  NUP:> DECnet    │
  4.  │   Judge Dredd    │ ║          Judge Dredd          ║ │Text File Archives│
  5.  └────────┬─────────┘ ║            File 24            ║ └─────────┬────────┘
  6.           │           ╚═══════════════════════════════╝           │
  7.           │           ╔═══════════════════════════════╗           │
  8.           └───────────╢ Computer Viruses & Threats II ╟───────────┘
  9.                       ╚═══════════════════════════════╝
  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.   and recover from potential incidents.
  121.  
  122.    Users should be educated about the following:
  123.  
  124.       - how malicious software  operates, methods by which  it is
  125.         planted  and  spread,  the  vulnerabilities exploited  by
  126.         malicious software and unauthorized users
  127.  
  128.       - general security policies  and procedures and how  to use
  129.         them
  130.  
  131.       - the policies to follow regarding the backup, storage, and
  132.         use of  software, especially  public-domain software  and
  133.         shareware
  134.  
  135.       - how  to use  the technical  controls they  have at  their
  136.         disposal to protect themselves
  137.  
  138.       - how to monitor their systems and software to detect signs
  139.         of abnormal activity, what  to do or whom to  contact for
  140.         more information
  141.  
  142.       - contingency procedures for containing and recovering from
  143.         potential incidents
  144.  
  145.    User education,  while perhaps  expensive in  terms  of time  and
  146.    resources required,  is ultimately a  cost-effective measure  for
  147.    protecting  against   incidents   of   malicious   software   and
  148.    unauthorized  use.  Users  who  are  better acquainted  with  the
  149.    destructive potential of  malicious software  and the methods  by
  150.    which it  can attack  systems may  in  turn be  prompted to  take
  151.    measures to protect themselves.  The purpose of security policies
  152.    and procedures will be more clear, thus users may be more willing
  153.    to actively use them.  By  educating users how to detect abnormal
  154.    system activity  and the resultant steps to follow for containing
  155.    and recovering from potential  incidents, organizations will save
  156.    money and time if and when actual incidents occur.
  157.  
  158. $_Software Management
  159.  
  160.  
  161.    As shown by  examples in File 1,  one of the prime  methods by
  162.    which malicious software  is initially copied onto  systems is by
  163.    unsuspecting users.   When users  download programs from  sources
  164.    such  as  software  bulletin  boards,  or public  directories  on
  165.    systems or network servers, or in  general use and share software
  166.    that has  not been obtained from a reputable source, users are in
  167.    danger of  spreading malicious software.   To prevent  users from
  168.    potentially spreading malicious software, managers need to
  169.  
  170.       - ensure  that  users understand  the  nature of  malicious
  171.         software,  how it is generally  spread, and the technical
  172.         controls to use to protect themselves
  173.  
  174.       - develop policies for  the downloading and use  of public-
  175.         domain and shareware software
  176.  
  177.       - create  some mechanism for validating such software prior
  178.         to allowing users to copy and use it
  179.  
  180.       - minimize the exchange  of executable  software within  an
  181.         organization as much as possible
  182.  
  183.       - do not create  software repositories on LAN servers or in
  184.         multi-user system directories  unless technical  controls
  185.         exist  to   prevent  users   from  freely   uploading  or
  186.         downloading the software
  187.  
  188.    The  role  of  education  is  important,  as  users  who  do  not
  189.    understand  the risks  yet who  are  asked to  follow necessarily
  190.    restrictive policies may share and  copy software anyway.   Where
  191.    technical controls  cannot prevent  placing new  software onto  a
  192.    system, users are  then primarily responsible for the  success or
  193.    failure of whatever policies are developed.
  194.  
  195.    A policy  that  prohibits any  copying  or use  of  public-domain
  196.    software  may  be  overly  restrictive,  as  some  public  domain
  197.    programs have proved  to be  useful.  A  less restrictive  policy
  198.    would  allow some  copying, however  a  user might  first require
  199.    permission from the appropriate manager.  A special system should
  200.    be used  from which  to perform  the copy  and then  to test  the
  201.    software.  This type of system, called an isolated system, should
  202.    be configured so that there is no risk of spreading a potentially
  203.    malicious program to other areas of  an organization.  The system
  204.    should  not  be  used  by  other  users, should  not  connect  to
  205.    networks, and should not contain any  valuable data.  An isolated
  206.    system should also be used  to test internally developed software
  207.    and updates to vendor software.
  208.  
  209.    Other policies for managing vendor  software should be developed.
  210.    These  policies  should   control  how  and  where   software  is
  211.    purchased, and should govern where the software  is installed and
  212.    how it is to be used.  The following policies and  procedures are
  213.    suggested:
  214.  
  215.       - purchase vendor software only from reputable sources
  216.  
  217.       - maintain the software properly and update it as necessary
  218.  
  219.       - don't use pirated software, as it may have been modified
  220.  
  221.       - keep  records  of  where  software is  installed  readily
  222.         available for contingency purposes
  223.  
  224.       - ensure that vendors can be  contacted quickly if problems
  225.         occur
  226.  
  227.       - store the original  disks or tapes  from the vendor in  a
  228.         secure location
  229.  
  230.  
  231. $_Technical Controls
  232.  
  233.    Technical  controls  are  the  mechanisms  used  to  protect  the
  234.    security and integrity of  systems and associated data.   The use
  235.    of technical controls can help  to prevent occurrences of viruses
  236.    and related threats by deterring them or making it more difficult
  237.    for them  to  gain access  to  systems  and data.    Examples  of
  238.    technical controls include user authentication mechanisms such as
  239.    passwords, mechanisms which provide selective levels of access to
  240.    files and directories  (read-only, no  access, access to  certain
  241.    users,  etc.),  and  write-protection  mechanisms  on  tapes  and
  242.    diskettes.
  243.  
  244.  
  245.    The different types of technical controls and the degree to which
  246.    they  can provide protection and deterrence varies from system to
  247.    system, thus the use  of specific types of controls  is discussed
  248.    in the following files.  However,  the following general points are
  249.    important to note:
  250.  
  251.       - technical  controls  should  be  used  as   available  to
  252.         restrict system access to authorized users only
  253.  
  254.       - in the multi-user environment, technical controls  should
  255.         be  used  to  limit  users'  privileges  to  the  minimum
  256.         practical level; they should work  automatically and need
  257.         not be initiated by users
  258.  
  259.       - users and system managers must be  educated as to how and
  260.         when to use technical controls
  261.  
  262.       - where  technical controls are weak or non-existent (i.e.,
  263.         personal  computers), they  should  be supplemented  with
  264.         alternative   physical   controls   or   add-on   control
  265.         mechanisms
  266.  
  267.    Managers need to determine which technical controls are available
  268.    on their systems,  and then the  degree to which  they should  be
  269.    used and whether  additional add-on controls are  necessary.  One
  270.    way  to  answer  these  questions  is  to  first  categorize  the
  271.    different classes of data being processed by a system or systems,
  272.    and then to  rank the  categories according to  criteria such  as
  273.    sensitivity to the  organization and vulnerability of  the system
  274.    to attack.  The rankings should then help determine the degree to
  275.    which  the  controls  should be  applied  and  whether additional
  276.    controls are  necessary.   Ideally, those systems  with the  most
  277.    effective controls should be used  to process the most  sensitive
  278.    data, and vice-versa.   As an example, a personal  computer which
  279.    processes  sensitive employee  information should  require add-on
  280.    user authentication mechanisms, whereas  a personal computer used
  281.    for general word processing may not need additional controls.
  282.  
  283.  
  284.    It is important to note that  technical controls do not generally
  285.    provide complete protection against viruses  and related threats.
  286.    They may be cracked by determined  users who are knowledgeable of
  287.    hidden  bugs and weaknesses,  and they may  be surmounted through
  288.    the use of Trojan horse programs, as shown by examples in File
  289.    1.  An  inherent weakness  in technical controls  is that,  while
  290.    deterring users and  software from objects  to which they do  not
  291.    have  access,  they may  be  totally ineffective  against attacks
  292.    which target objects that are accessible.  For example, technical
  293.    controls may not prevent an authorized user from destroying files
  294.    to which the user has authorized  access.  Most importantly, when
  295.    technical controls  are not  used properly, they  may increase  a
  296.    system's  degree of vulnerability.   It is  generally agreed that
  297.    fully effective technical  controls will not be  widely available
  298.    for some time.   Because of the immediate nature of  the computer
  299.    virus threat,  technical controls  must be  supplemented by  less
  300.    technically-oriented control  measures such as  described in this
  301.    chapter.
  302.  
  303. $_General Monitoring
  304.  
  305.    An  important aspect of  computer viruses and  related threats is
  306.    that they  potentially can cause  extensive damage within  a very
  307.    small amount of time, such as minutes or seconds.  Through proper
  308.    monitoring of software, system activity,  and in some cases  user
  309.    activity,  managers  can increase  their  chances that  they will
  310.    detect   early  signs  of  malicious  software  and  unauthorized
  311.    activity.  Once the presence is  noted or suspected, managers can
  312.    then  use  contingency  procedures to  contain  the  activity and
  313.    recover  from whatever  damage has  been  caused.   An additional
  314.    benefit of  general monitoring is that  over time, it can  aid in
  315.    determining  the  necessary  level  or   degree  of  security  by
  316.    indicating  whether security  policies, procedures,  and controls
  317.    are working as planned.
  318.  
  319.    Monitoring  is  a  combination  of  continual system  and  system
  320.    management activity.   Its effectiveness  depends on  cooperation
  321.    between management and users.   The following items are necessary
  322.    for effective monitoring:
  323.  
  324.       - user  education  -  users must  know,  specific  to their
  325.         computing  environment,  what   constitutes  normal   and
  326.         abnormal system activity and whom  to contact for further
  327.         information - this  is especially important for  users of
  328.         personal  computers,  which   generally  lack   automated
  329.         methods for monitoring
  330.  
  331.       - automated system  monitoring tools - generally  on multi-
  332.         user systems, to  automate logging or accounting  of user
  333.         and  software  accesses  to accounts,  files,  and  other
  334.         system objects  - can sometimes  be tuned to  record only
  335.         certain types of accesses such as "illegal" accesses
  336.  
  337.       - anti-viral software  - generally  on personal  computers,
  338.         these tools alert users of certain types of system access
  339.         that are indicative of "typical" malicious software
  340.  
  341.       - system-sweep programs  - programs to  automatically check
  342.         files for changes in size, date, or content
  343.  
  344.       - network  monitoring  tools -  as  with system  monitoring
  345.         tools, to record network accesses or attempts to access
  346.  
  347.    The statistics gained  from monitoring activities should  be used
  348.    as input for periodic reviews of  security programs.  The reviews
  349.    should  evaluate the effectiveness  of general system management,
  350.    and associated security policies, procedures,  and controls.  The
  351.    statistics will indicate  the need for  changes and will help  to
  352.    fine tune the program so that security is distributed to where it
  353.    is most necessary.   The reviews  should also incorporate  users'
  354.    suggestions,  and  to  ensure  that  the program  is  not  overly
  355.    restrictive, their criticisms.
  356.  
  357. $_Contingency Planning
  358.  
  359.  
  360.    The  purpose  of  contingency planning  with  regard  to computer
  361.    viruses and related threats is to be able to  contain and recover
  362.    completely from  actual attacks.  In many  ways, effective system
  363.    management  that  includes  user  education,  use   of  technical
  364.    controls,  software management,  and monitoring activities,  is a
  365.    form  of  contingency  planning, generally  because  a  well-run,
  366.    organized  system  or facility  is better  able to  withstand the
  367.    disruption that could  result from a  computer virus attack.   In
  368.    addition to effective system management activities, managers need
  369.    to consider  other contingency procedures that  specifically take
  370.    into account the nature of computer viruses and related threats.
  371.  
  372.    Possibly  the  most   important  contingency  planning   activity
  373.    involves the use of backups.  The ability to recover from a virus
  374.    attack depends upon maintaining regular,  frequent backups of all
  375.    system data.   Each backup should be  checked to ensure  that the
  376.    backup media has not  been corrupted.  Backup media  could easily
  377.    be corrupted because of defects, because the backup procedure was
  378.    incorrect, or perhaps because the backup software itself has been
  379.    attacked and modified to corrupt backups as they are made.
  380.  
  381.    Contingency procedures for  restoring from backups after  a virus
  382.    attack  are equally  important.   Backups may  contain  copies of
  383.    malicious  software  that   have  been  hiding  in   the  system.
  384.    Restoring  the  malicious software  to  a  system  that has  been
  385.    attacked could  cause a recurrence of the problem.  To avoid this
  386.    possibility, software should  be restored only from  its original
  387.    media:   the tapes or diskettes from the  vendor.  In some cases,
  388.    this may  involve reconfiguring the software,  therefore managers
  389.    must maintain copies of configuration  information for system and
  390.    application software.   Because data is not  directly executable,
  391.    it  can be restored from routine backups.  However, data that has
  392.    been  damaged  may need  to be  restored  manually or  from older
  393.    backups.    Command files  such  as  batch  procedures and  files
  394.    executed  when  systems  boot  or  when  user log  on  should  be
  395.    inspected to ensure that they have  not been damaged or modified.
  396.    Thus,  managers  will  need  to  retain  successive  versions  of
  397.    backups, and search through them when restoring  damaged data and
  398.    command files.
  399.  
  400.    Other contingency procedures for containing virus attacks need to
  401.    be developed.  The following are suggested; they are discussed in
  402.    more detail in following files:
  403.  
  404.  
  405.       - ensure that accurate  records are  kept of each  system's
  406.         configuration,  including  the  system's   location,  the
  407.         software  it   runs,  the  system's  network   and  modem
  408.         connections,  and  the name  of  the system's  manager or
  409.         responsible individual
  410.  
  411.       - create a  group  of  skilled users  to  deal  with  virus
  412.         incidents and ensure that users  can quickly contact this
  413.         group if they suspect signs of viral activity
  414.  
  415.       - maintain a security  distribution list at each  site with
  416.         appropriate telephone numbers of managers to contact when
  417.         problems occur
  418.  
  419.       - isolate critical systems from  networks and other sources
  420.         of infection
  421.  
  422.       - place outside  network connections  on  systems with  the
  423.         best  protections,  use  central  gateways to  facilitate
  424.         rapid disconnects
  425.  
  426. -JUDGE DREDD/NIA
  427.  
  428. [OTHER WORLD BBS]
  429.