home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 1 / HACKER1.ISO / network / nia28 < prev    next >
Text File  |  1992-09-26  |  25KB  |  494 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 :       Guardian Of Time        : 3Text File Archives3
  5.   @DDDDDDDDBDDDDDDDDDY :            File 28            : @DDDDDDDDDBDDDDDDDDY
  6.            3           HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<           3
  7.            3            IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM;           3
  8.            @DDDDDDDDDDDD: COMPUTER SECURITY TECHNIQUES :DDDDDDDDDDDY
  9.                         :   Section II - Background    :
  10.                         HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<
  11.  
  12. Here is Section II of VI Sections that talks in some detail about Computer
  13. Crime,  and also sights actual court cases, which may be of some help to
  14. you.
  15.  
  16.  
  17.                           SECTION II - BACKGROUND
  18.  
  19. $COMPUTER SECURITY BEGINNINGS
  20.  
  21. Although computer security has been an important requirement in the
  22. military since computer use began, it has been only explicitly recognized
  23. in nonmilitary government and business since the late 1960s.  The 1967
  24. American Federation of Information Processing Societies, Spring Joint
  25. Computer Conference session, "Security and Privacy in Computer
  26. Systems" chaired by Dr.  Willis Ware of the Rand Corporation, generated new
  27. interest in computer security.  Rapid development, stimulated by the
  28. privacy issues and notorious computer crimes in the 1970s, has followed.
  29. Formalized methods for evaluating the adequacy of security soon followed.
  30.  
  31.  
  32. On July 27, 1978, the US Office of Management and Budget issued to all
  33. agency heads the Transmittal Memorandum No.1  under Circular No.A-71 on
  34. Security of Federal Automated Information Systems.  This memorandum
  35. presents a comprehensive policy regarding establishment of computer
  36. security programs in all nondefense computer centers.  It contains a
  37. procedure for adopting security standards, a requirement for security in
  38. all hardware and software procurements, plus guidance on security in all
  39. hardware and software procurements, plus guidance on conducting risk
  40. analyses, performing security audits, developing contingency plans, and
  41. establishing personal security policies.  Various roles for the National
  42. Bureau of Standards, General Services Administration, and Civil SErvice
  43. Commission are specified.  This memorandum, a significant milestone for
  44. computer security in the federal government, is a well-conceived document
  45. worth of general use.
  46.  
  47. $MATURING COMPUTER SECURITY
  48.  
  49. New approaches to reviewing, establishing the needs for, and selecting
  50. computer security controls are emerging as concepts of computer security
  51. mature.  Maturation is evident from the routine acceptance  of security
  52. and from the type of controls typically used today at the seven sites
  53. visited.  At present, the computer security field is characterized by:
  54.  
  55. :      General management recognition and support.
  56.  
  57.        Top management at the sites were interested enough in computer
  58.        Security to fully cooperate with the project field teams.  Corporate
  59.        and agency policies reflecting top management's concern have been
  60.        formulated.
  61.  
  62. :      Established specialists in the subject area.
  63.  
  64.        Full-time security researchers and designers in computer science
  65.        and technology are developing concepts of trusted computer systems
  66.        that will be significantly more secure than current computers.
  67.        Many consultants are active in the field.  Computer security job
  68.        titles and positions have been developed, and hiring by these
  69.        titles is practiced.
  70.  
  71. :      Appointment of full-time or part-time computer security officers in
  72.        large,  well-run computer installations.
  73.  
  74.        The larger organization visited had full-time or part-time computer
  75.        security officers.  National conferences on computer and computer
  76.        security and privacy are currently drawing 700 to 800 computer
  77.        security-rated specialists and administrators.
  78.  
  79. :      Computer security products available at resonable prices.
  80.  
  81.        Physical access control systems for computer centers, password
  82.        access terminal systems, file access control computer programs,
  83.        file detection and suppression equipment, cryptographic systems,
  84.        audit program tools and uninterrruptible power supplies for
  85.        continuous operation of computers are examples of resonable priced
  86.        products ( see also Section VI).  In Addtion, the products'
  87.        salesmen provide a new source of information and assistance for
  88.        security practitioners.
  89.  
  90. :      A precedent-setting federal standard for cryptographic protection.
  91.  
  92.        The first federal information processing standard,  the Data
  93.        Encryption Standard, was approved by the National Bureau of
  94.        Standards and is used in more than 25 products.
  95.  
  96. :      Increasing numbers of effective controls found in well-run computer
  97.        installations and well-designed systems.
  98.  
  99.        Section VI identifies 82 generally used controls based on field
  100.        investigation of the seven computer sites.
  101.  
  102. :      Practice of formal security review methods.
  103.  
  104.        Task group reviews of computer centers are becoming more common.
  105.        The US Office of Management and Budget requires that risk
  106.        assessments be performed in all federal agency computer centers at
  107.        least once every 3 years.  The National Bureau of Standards has
  108.        published several reports on conducting risk assessments.
  109.  
  110. :      A body of information documenting loss experience.
  111.  
  112.        Conference proceedings, books, and trade journals include detailed
  113.        descriptions of loss cases.  Mr. Donn B. Parker at SRI
  114.        International, Professor Brandt Allen at the University of Virginia,
  115.        The American Institute Of Certified Public Accountants, Mr.  Robert
  116.        Courtney in New York, and Mr.  Jay Bloombecker in Los Angeles have
  117.        extensive files of reported computer abuse and crime cases.
  118.  
  119. :      Laws and regulations requiring security.
  120.  
  121.        The Federal and State Privacy Acts, Foreign Corrupt Practices Act,
  122.        16 state computer crime statues, and numerous regulations require
  123.        or directly imply the need for controls.
  124.  
  125. :      Special insurance polices.
  126.  
  127.       Numerous insurance companies offer policies for protection against
  128.       data processing business interruption, errors and ommissions, and
  129.       crime.
  130.  
  131. :      Numerous books, journals, news publications, and other writings on
  132.        the subject.
  133.  
  134.        The National Bureau of Standards has published more than 40
  135.        computer security reports.  The Bureau of Justice Statistics,
  136.        Department of Justice, has published a series of manuals and guides
  137.        on privacy and security.  At least four monthly commerical
  138.        newsletters and journals, as well as many books on computer
  139.        security, are published.
  140.  
  141. :     Specialized audit capabilities.
  142.  
  143.       The Institute of Internal Auditors published the SRI international
  144.       Systems Auditability and Control Reports identifying 30 audit
  145.       techniques and more than 300 controls.  EDP auditing has become an
  146.       accepted specialty in audit, and EDP auditors are certified by the
  147.       Institute of Internal Auditors and soon also by the EDP Auditors
  148.       Association.
  149.  
  150. $VULNERABILITIES
  151.  
  152. Admittedly, some potential threats and assets subject to loss are
  153. different from one computer center to another depending on organizational
  154. characteristics and purposes.  Some vulnerabilities of a US Department of
  155. Justice computer center will be different than a toy manufacturer's
  156. computer center.  However, similar problems among even diverse kinds of
  157. computer centers can lead to adoption of commonly used controls.  The
  158. potential threats, the assets at risk, and the vulnerable facilities that
  159. are similar among all computer centers include:
  160.  
  161. :  Potential Threats
  162.    - Disgruntled or error-prone employees causing physical destruction and
  163.      destruction or modification of programs or data.
  164.    - Natural disaster such as fire, flooding, and loss of power and
  165.      communications.
  166.    - Outsiders or employees making unauthorized use of computer services.
  167.    - Outsiders or employees taking computer programs, data, equipment or
  168.      supplies.
  169.  
  170. :  Assets Subject To Loss
  171.    - Facilities
  172.    - Systems equipment
  173.    - People
  174.    - Computer programs
  175.    - Data
  176.    - Data storage media
  177.    - Supplies
  178.    - Services
  179.    - Documents
  180.    - Records
  181.    - Public respect and reputation.
  182.  
  183. :  Common Environments at Risk
  184.    - Computer rooms containing computers and peripheral equipment
  185.    - Magnetic media (tapes and disks) libraries
  186.    - Job setup and output distribution stations
  187.    - Data entry capabilities
  188.    - Program libraries
  189.    - Program development offices
  190.    - Utility rooms
  191.    - Reception areas
  192.    - Communications switching panels
  193.    - Fire detection and suppression equipment
  194.    - Backup storage
  195.    - Logs, records, and journals.
  196.  
  197. In addition to the vulnerabilities common to all computer centers, some
  198. types of computer centers such as criminal justice operations, research
  199. institutes, insurance companies, and banks have environments,
  200. applications, and types of data that create similar potential threats and
  201. types of asset loss.  The vulnerabilities endemic to subsets of similar
  202. computer centers lead to the need for selective controls such as
  203. separation or deletion of names from personal data, batch check summing of
  204. inventory data and possibly data encryption.  Some examples of computer
  205. applications and associated risks that are not common to all computer
  206. centers are as follows:
  207.  
  208. :  Processing and storage of personal data
  209.    - Intentional or accidental disclosure, modification, destruction or
  210.      use of personal data or records of their use.
  211.    - Violation of confidentiality rules, personal data regulations, or
  212.      privacy laws.
  213.  
  214. :  Processing and storage of secret data (eg, investigative, intelligence,
  215.    trade secret, marketing, competitive).
  216.    - Intentional or accidental disclosure, modification, destruction, or
  217.      use of trade secret or sensitive data or records.
  218.    - Violation of rules, regulations, or laws.
  219.  
  220. :  Processing and storage of financial data (eg, account balances,
  221.    negotiable instruments input/output, general ledger, accounts
  222.    payable/receivable, payroll).
  223.    - Financial fraud or theft.
  224.    - Accidental financial loss such as lost interest.
  225.    - Failure to meet financial report filing dates and other fiduciary
  226.      obligations.
  227.  
  228. :  Process control (eg, controlling manufacturing processes,
  229.    transportation, meal processing, inventory control, patient
  230.    monitoring).
  231.    - Intentional or accidental modification, failure, or destruction of
  232.      processes.
  233.  
  234. In addition, special or unique problems can arise in a single computer
  235. center where new technology is adopted and commonly used controls have not
  236. yet emerged.  Examples of the new technology include voice data entry,
  237. voice ouput, fiber optics communication, satellite data communications,
  238. and automated offices.
  239.  
  240. Lastly, several potential sources of unusual threats requiring special
  241. controls have been identified: a computer center built over a burning
  242. underground coal mine, violent labor strife, a computer center in an
  243. airport glide path, rodent or insect infestation, and contract programming
  244. performed by prison inmates.
  245.  
  246. $CURRENT SECURITY REVIEW AND CONTROL SELECTION PRACTICES
  247.  
  248. The process of identifying security needs and selecting and justifying
  249. controls is called a security review when carried out in an organized set
  250. of scheduled and budgeted tasks.  It is sometimes incorrectly called an
  251. audit.  An audit implies independent review by auditors for top management
  252. and owners of an enterprise to discover problems and lack of compliance with
  253. law, regulations, and policy.
  254.  
  255. The security review method described below is based on identification of
  256. assets, potential threats, and lack of controls.  A zero-based method, it
  257. begins by assuming that potential threats and controls have not been
  258. adequately addressed previously.  Its purpose is to comprehensively and
  259. exhaustively identify problems in the form of specific vulnerabilities,
  260. their risk, and compensating controls.  This approach is thoroughly
  261. justified; losses tend to occur where effective controls are absent.
  262.  
  263. $A COMMONLY RECOMMENDED REVIEW METHOD
  264.  
  265. The usual method of security review often described in the literature and
  266. in seminars includes combinations and various oderings of the following
  267. steps:
  268.  
  269. (1)  Organize a task group to conduct the review; establish plans,
  270.      assignments, schedules, budgets, and scope; obtain management
  271.      approval and support of the plan.
  272.  
  273. (2)  Identify the assets subject to loss; either determine their value,
  274.      consequences of loss, and replacement value or rank their importance.
  275.  
  276. (3)  Identify potential threats to the identified assets.
  277.  
  278. (4) Identify the controls in place or lack of controls that mitigate or
  279.     facilitate the potential threats to the assets.
  280.  
  281. (5)  Combine associated potential threats, assets subject to loss, and
  282.      lack of mitigating controls; each triple of items constitutes a
  283.      vulnerability.
  284.  
  285. (6)  Evaluate and rank the vulnerabilities in terms of greatest to least
  286.      expected potential loss; alternatively quantify risk for all or only
  287.      the major vulnerabilities in terms of annual frequency of loss and
  288.      single case loss in dollars to obtain annualized loss exposure.
  289.  
  290. (7)  Identify actions and controls that would reduce the risks of losses
  291.      to acceptably low levels.
  292.  
  293. (8)  Recommend an implementation plan to reduce risk to an overall
  294.      acceptably low level.
  295.  
  296. (9)  Carry out the plan and establish ongoing security maintenance and
  297.      improvements.
  298.  
  299. Several steps may be combined or overlapped for task group operating
  300. efficiency.  Various methods such as use of questionnaires and loss and
  301. frequency data forms or scenarios can aid in accomplishing the tasks and
  302. documenting the results.  Some steps may involve a high volume of data to
  303. warrant use of computer-aided methods.  For example, quantified risk
  304. assessment requires expected frequency of loss and dollar value of single
  305. incident loss from both intentional and accidental modification,
  306. destruction, disclosure, use and denial of use (for various periods of
  307. time) for all computer-related threats and assets.
  308.  
  309. In practice, however, the formalized review approach is rarely taken, or
  310. only severely limited versions are adopted.  More likely, only piecemeal
  311. discoveries of vulnerabilities and their solutions happen.  These events
  312. are occasioned by other information processing activities such as audits,
  313. loss events, new applications, new or newly enforced requirements,
  314. contracting, or budget studies.  If a specific study is conducted, often
  315. obvious, significant vulnerabilities are identified early and actions
  316. taken to reduce their risk even before the final recommendations are made.
  317.  
  318. $SECUIRTY METHODS IN PRACTICE
  319.  
  320. A survey of management practices was conducted at the seven field sites.Managers
  321. were asked to describe the process curretnly used to select, justify, and
  322. install computer security controls.  Both methodology and organizational factors
  323. were studied.  Three typical case studies for a government agency, a research
  324. organization, and a private sector firm are included in Appendix A.
  325.  
  326. None of the organizations studied used a formal cost-benifit or risk analysis to
  327. evaluate computer security controls.  These techniques, which have been heralded
  328. in the literature, were thought to be excesively elaborate and not
  329. cost-effective.  Quantitative analyses were considered not appropriate because
  330. of a lack of valid data.  Instead, each site primarily used subjective and
  331. somewhat informal piecemeal techniques for assessing the pros and cons of
  332. particular computer security controls.
  333.  
  334. These subjective techniques can be described as the exercise of prudent care or
  335. subscribing to generally used controls.  the words "prudence" and "common sense"
  336. were frequently used in describing what went into these subjective assessment
  337. approaches.  Generally used approaches were defined in terms of the practices of
  338. other organizations in similar environments.  Management essentially asked, "If
  339. another manager were in my place, would he install and operate the proposed
  340. control?"  Factors considered in answering this questing include:
  341.  
  342. :  The controls actually being used by other orgainziations with similar
  343.    applications and equipment.
  344.  
  345. :  Reported loss experience.
  346.  
  347. :  The perceived needs of the organization's own operating environment
  348.    compared to other organizations with similar environments.
  349.  
  350. :  The increased level of security to be achieved.
  351.  
  352. : Laws and regulations.
  353.  
  354. Definitions of generally used controls typically consider a wideranging
  355. control environment.  Policies and professional ethical mores, personnel
  356. procedures, and manual procedures can be used to make up for the possible
  357. lack of computer-based controls, especially in computer systems where
  358. security has not been a design and implementation criterion.
  359.  
  360. Another important factor in the decision to use a particular control was the
  361. influence of outside parties.  Clients served by the organizations specified
  362. requirements that had to be met before certain work could be performed and
  363. data could be obtained.  these requirements mirrored requirements that in
  364. some instances came from within the organization.  External and internal
  365. auditors were other sources of relevant information.  Quantitative
  366. information such as the cost to install and operate a control, money to be
  367. saved, or the losses to be prevented ( from catastrophes, lawsuits, or
  368. public embarrassment ) were rarely considered.
  369.  
  370. Management in most cases did not actively seek information about what is
  371. done elsewhere.  Although they used this information when made available to
  372. them and found it to be of great interest and potentially useful, they did
  373. not believe that contacting similar organizations and asking questions were
  374. cost-effective.  The exception to this occurred when very costly controls,
  375. such as vaults or electronic lock access systems, were considered.
  376. Management then directed technical personnel to study alternative products
  377. and survey users of the products.  Sometimes prioritized lists of desirable
  378. controls were prepared as wish lilsts that could be reviewed whenever
  379. budgets were prepared.  The lists were helpful in matching high-priority
  380. controls with limited resources.  Controls were viewed as necessary
  381. resource-consuming items rather than revenue generating or cost-saving
  382. items.  The time frame was typically 3 to 5 years.
  383.  
  384. The source of the funds to be used for a control largely dictated the
  385. approval process; if funds were to come from a government grant, from
  386. organizational overhead, or from a client project, then the approval
  387. channels were markedly different in each case.  The approvoal process also
  388. varied depending on the time of year when the need for a control was
  389. noticed.  If a need was perceived shortly before budgets were prepared, and
  390. installation could be delayed until the next fiscal year, then it was
  391. included in the budget.  If installation of a control could not be delayed
  392. until the next fiscal year, then it was included in the budget.  If
  393. installation of a control could not be delayed until the next fiscal year,
  394. special procedures were requried to rearrange currently budgeted funds to
  395. obtain additional funds.
  396.  
  397. Documentation of the decision process was often sparce.  Purchase
  398. requisitions and budgets on the proposed control were sometimes the only
  399. formal documents produced.  Explicit management approval in these cases was
  400. given when these forms were approved.  Larger organization werre more liekly
  401. to require formal documentation that included proposals, signoff sheets,
  402. memos, impact statements, and in rare instances cost-benefit analyses.
  403. Systems development and modification methodologies in some cases included
  404. requirements for considering computer security.  Security was reviewed when
  405. a system was designed, redesigned, or modified, but not otherwise.  The
  406. concern for security was not dealt with in isolation from other activites.
  407. Typically, a control that was retroisolation from other activites.
  408. Typically, a control that was retrofitted to an existing system was
  409. evaluated in the same manner as a control that was originally designed into
  410. a system.  Both were subject to the system development and modification
  411. methodology.
  412.  
  413. Documentation of control decisions and the resulting changes to be made were
  414. more extensive whenever a control was going to affect people outside the
  415. organization.  One organization wrote and maintained a specialized secure
  416. operating system; another developed and installed a security program
  417. package.  For these products, strict requirements for system change
  418. justification and documentation existed.
  419.  
  420. $DECISION-MAKING FACTORS
  421.  
  422. Typically, the decision to adopt a control was made by the line managers
  423. from the area primarily involved; for example, if an electronic lock access
  424. system would restrict the activities of computer operators, then compuer
  425. operations management would make the decision.
  426.  
  427. In some instances, security committees that had an advisory role in the
  428. decision to adopt computer security controls were formed.  These committees
  429. were composed of higher level managers who represented the following
  430. organizational ares:  The legal department, user organizations, applications
  431. development, computer operations, and industrial security.  These committees
  432. monitored legal and regulatory requirements , current events, and the
  433. current security systems.  In rare cases, the committee had approval
  434. authority.
  435.  
  436. When a proposed control affected several parts of the organization in a
  437. significant monetary or operational way, then management approval of each of
  438. these areas was usually obtained.  Approval by industrial security, legal
  439. counsel, audit, personnel, users, as well as other departments of a compute
  440. center besides the one proposing a control was thus sometimes requred.  For
  441. example, if a control would increase the rates for computing services
  442. charged to users, or if it would change the user's interaction with a
  443. computer system, then the users would typically be involved in the decision
  444. process.  Occasionally, if many areas were involved, then a higher level
  445. manager who had each of these areas reporting to him decided whether to
  446. adopt a proposed control.
  447.  
  448. The computer service provider may play different roles in the identification
  449. and approval of the need for a control.  The service provider in some cases
  450. was responisble for telling the user what was needed, while in other
  451. organizations the user was responisble for telling the service provider what
  452. was required.  In either case, expertise within the computer sevice
  453. provider's organization was relied on.  In some organizations, other
  454. departments such as audit and legal counsel were supposed to alert involved
  455. parties to the need for additional controls, but the approval of the changes
  456. still rested with the service provider and the user.
  457.  
  458. Audit departments were seldom involved in the control requirements and
  459. specification process.  Although many authors of computer security works
  460. advocate that auditors be involved in systems design work, this
  461. participation did not generally occur.  Some say that this sytem is
  462. adequate--auditors are not supposed to directly participate, which
  463. specification of controls would imply.  Auditors were said to only
  464. infrequently review computer controls.  Others state that auditors should be
  465. more active in the review of controls, informing management of the need for
  466. improvements.  Larger organizations were more likely to have auditing staff
  467. involved in these activities.
  468.  
  469. Many installations have noted that finding security experts in the computer
  470. field to hire is a problem.  In some cases controls were not evaluated or
  471. implemented because of the lack of qualified personnel.  the shortage of
  472. experts in the computer security field is particularly acute.
  473.  
  474. Evidence of the maturing of computer security and the findings from
  475. experience about selection of controls provide the background to consider
  476. the motivation and need for adopting generally used controls.  The next
  477. section provides two specific examples of common sources of this motivation
  478. and need and how they may be satisfied by generally used controls.
  479.  
  480. This section has described the increased recognition of the ned for security
  481. controls and the maturation and status of the process of control selection.
  482. a major factor relevant to decision making regarding computer security is
  483. the legal framework surrondin data and releated computer violations and
  484. liabilities.  These issues are addressed in the next section.
  485.  
  486. $EOF
  487.  
  488. [OTHER WORLD BBS]
  489.  
  490.  
  491.  
  492.  
  493. Downloaded From P-80 International Information Systems 304-744-2253 12yrs+
  494.