Copy Link
Add to Bookmark
Report

Network Information Access 28

  

ZDDDDDDDDDDDDDDDDDD? IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM; ZDDDDDDDDDDDDDDDDDD?
3 Founded By: 3 : Network Information Access : 3 Mother Earth BBS 3
3 Guardian Of Time 3D: 17APR90 :D3 NUP:> DECnet 3
3 Judge Dredd 3 : Guardian Of Time : 3Text File Archives3
@DDDDDDDDBDDDDDDDDDY : File 28 : @DDDDDDDDDBDDDDDDDDY
3 HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM< 3
3 IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM; 3
@DDDDDDDDDDDD: COMPUTER SECURITY TECHNIQUES :DDDDDDDDDDDY
: Section II - Background :
HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<

Here is Section II of VI Sections that talks in some detail about Computer
Crime, and also sights actual court cases, which may be of some help to
you.


SECTION II - BACKGROUND

$COMPUTER SECURITY BEGINNINGS

Although computer security has been an important requirement in the
military since computer use began, it has been only explicitly recognized
in nonmilitary government and business since the late 1960s. The 1967
American Federation of Information Processing Societies, Spring Joint
Computer Conference session, "Security and Privacy in Computer
Systems" chaired by Dr. Willis Ware of the Rand Corporation, generated new
interest in computer security. Rapid development, stimulated by the
privacy issues and notorious computer crimes in the 1970s, has followed.
Formalized methods for evaluating the adequacy of security soon followed.


On July 27, 1978, the US Office of Management and Budget issued to all
agency heads the Transmittal Memorandum No.1 under Circular No.A-71 on
Security of Federal Automated Information Systems. This memorandum
presents a comprehensive policy regarding establishment of computer
security programs in all nondefense computer centers. It contains a
procedure for adopting security standards, a requirement for security in
all hardware and software procurements, plus guidance on security in all
hardware and software procurements, plus guidance on conducting risk
analyses, performing security audits, developing contingency plans, and
establishing personal security policies. Various roles for the National
Bureau of Standards, General Services Administration, and Civil SErvice
Commission are specified. This memorandum, a significant milestone for
computer security in the federal government, is a well-conceived document
worth of general use.

$MATURING COMPUTER SECURITY

New approaches to reviewing, establishing the needs for, and selecting
computer security controls are emerging as concepts of computer security
mature. Maturation is evident from the routine acceptance of security
and from the type of controls typically used today at the seven sites
visited. At present, the computer security field is characterized by:

: General management recognition and support.

Top management at the sites were interested enough in computer
Security to fully cooperate with the project field teams. Corporate
and agency policies reflecting top management's concern have been
formulated.

: Established specialists in the subject area.

Full-time security researchers and designers in computer science
and technology are developing concepts of trusted computer systems
that will be significantly more secure than current computers.
Many consultants are active in the field. Computer security job
titles and positions have been developed, and hiring by these
titles is practiced.

: Appointment of full-time or part-time computer security officers in
large, well-run computer installations.

The larger organization visited had full-time or part-time computer
security officers. National conferences on computer and computer
security and privacy are currently drawing 700 to 800 computer
security-rated specialists and administrators.

: Computer security products available at resonable prices.

Physical access control systems for computer centers, password
access terminal systems, file access control computer programs,
file detection and suppression equipment, cryptographic systems,
audit program tools and uninterrruptible power supplies for
continuous operation of computers are examples of resonable priced
products ( see also Section VI). In Addtion, the products'
salesmen provide a new source of information and assistance for
security practitioners.

: A precedent-setting federal standard for cryptographic protection.

The first federal information processing standard, the Data
Encryption Standard, was approved by the National Bureau of
Standards and is used in more than 25 products.

: Increasing numbers of effective controls found in well-run computer
installations and well-designed systems.

Section VI identifies 82 generally used controls based on field
investigation of the seven computer sites.

: Practice of formal security review methods.

Task group reviews of computer centers are becoming more common.
The US Office of Management and Budget requires that risk
assessments be performed in all federal agency computer centers at
least once every 3 years. The National Bureau of Standards has
published several reports on conducting risk assessments.

: A body of information documenting loss experience.

Conference proceedings, books, and trade journals include detailed
descriptions of loss cases. Mr. Donn B. Parker at SRI
International, Professor Brandt Allen at the University of Virginia,
The American Institute Of Certified Public Accountants, Mr. Robert
Courtney in New York, and Mr. Jay Bloombecker in Los Angeles have
extensive files of reported computer abuse and crime cases.

: Laws and regulations requiring security.

The Federal and State Privacy Acts, Foreign Corrupt Practices Act,
16 state computer crime statues, and numerous regulations require
or directly imply the need for controls.

: Special insurance polices.

Numerous insurance companies offer policies for protection against
data processing business interruption, errors and ommissions, and
crime.

: Numerous books, journals, news publications, and other writings on
the subject.

The National Bureau of Standards has published more than 40
computer security reports. The Bureau of Justice Statistics,
Department of Justice, has published a series of manuals and guides
on privacy and security. At least four monthly commerical
newsletters and journals, as well as many books on computer
security, are published.

: Specialized audit capabilities.

The Institute of Internal Auditors published the SRI international
Systems Auditability and Control Reports identifying 30 audit
techniques and more than 300 controls. EDP auditing has become an
accepted specialty in audit, and EDP auditors are certified by the
Institute of Internal Auditors and soon also by the EDP Auditors
Association.

$VULNERABILITIES

Admittedly, some potential threats and assets subject to loss are
different from one computer center to another depending on organizational
characteristics and purposes. Some vulnerabilities of a US Department of
Justice computer center will be different than a toy manufacturer's
computer center. However, similar problems among even diverse kinds of
computer centers can lead to adoption of commonly used controls. The
potential threats, the assets at risk, and the vulnerable facilities that
are similar among all computer centers include:

: Potential Threats
- Disgruntled or error-prone employees causing physical destruction and
destruction or modification of programs or data.
- Natural disaster such as fire, flooding, and loss of power and
communications.
- Outsiders or employees making unauthorized use of computer services.
- Outsiders or employees taking computer programs, data, equipment or
supplies.

: Assets Subject To Loss
- Facilities
- Systems equipment
- People
- Computer programs
- Data
- Data storage media
- Supplies
- Services
- Documents
- Records
- Public respect and reputation.

: Common Environments at Risk
- Computer rooms containing computers and peripheral equipment
- Magnetic media (tapes and disks) libraries
- Job setup and output distribution stations
- Data entry capabilities
- Program libraries
- Program development offices
- Utility rooms
- Reception areas
- Communications switching panels
- Fire detection and suppression equipment
- Backup storage
- Logs, records, and journals.

In addition to the vulnerabilities common to all computer centers, some
types of computer centers such as criminal justice operations, research
institutes, insurance companies, and banks have environments,
applications, and types of data that create similar potential threats and
types of asset loss. The vulnerabilities endemic to subsets of similar
computer centers lead to the need for selective controls such as
separation or deletion of names from personal data, batch check summing of
inventory data and possibly data encryption. Some examples of computer
applications and associated risks that are not common to all computer
centers are as follows:

: Processing and storage of personal data
- Intentional or accidental disclosure, modification, destruction or
use of personal data or records of their use.
- Violation of confidentiality rules, personal data regulations, or
privacy laws.

: Processing and storage of secret data (eg, investigative, intelligence,
trade secret, marketing, competitive).
- Intentional or accidental disclosure, modification, destruction, or
use of trade secret or sensitive data or records.
- Violation of rules, regulations, or laws.

: Processing and storage of financial data (eg, account balances,
negotiable instruments input/output, general ledger, accounts
payable/receivable, payroll).
- Financial fraud or theft.
- Accidental financial loss such as lost interest.
- Failure to meet financial report filing dates and other fiduciary
obligations.

: Process control (eg, controlling manufacturing processes,
transportation, meal processing, inventory control, patient
monitoring).
- Intentional or accidental modification, failure, or destruction of
processes.

In addition, special or unique problems can arise in a single computer
center where new technology is adopted and commonly used controls have not
yet emerged. Examples of the new technology include voice data entry,
voice ouput, fiber optics communication, satellite data communications,
and automated offices.

Lastly, several potential sources of unusual threats requiring special
controls have been identified: a computer center built over a burning
underground coal mine, violent labor strife, a computer center in an
airport glide path, rodent or insect infestation, and contract programming
performed by prison inmates.

$CURRENT SECURITY REVIEW AND CONTROL SELECTION PRACTICES

The process of identifying security needs and selecting and justifying
controls is called a security review when carried out in an organized set
of scheduled and budgeted tasks. It is sometimes incorrectly called an
audit. An audit implies independent review by auditors for top management
and owners of an enterprise to discover problems and lack of compliance with
law, regulations, and policy.

The security review method described below is based on identification of
assets, potential threats, and lack of controls. A zero-based method, it
begins by assuming that potential threats and controls have not been
adequately addressed previously. Its purpose is to comprehensively and
exhaustively identify problems in the form of specific vulnerabilities,
their risk, and compensating controls. This approach is thoroughly
justified; losses tend to occur where effective controls are absent.

$A COMMONLY RECOMMENDED REVIEW METHOD

The usual method of security review often described in the literature and
in seminars includes combinations and various oderings of the following
steps:

(1) Organize a task group to conduct the review; establish plans,
assignments, schedules, budgets, and scope; obtain management
approval and support of the plan.

(2) Identify the assets subject to loss; either determine their value,
consequences of loss, and replacement value or rank their importance.

(3) Identify potential threats to the identified assets.

(4) Identify the controls in place or lack of controls that mitigate or
facilitate the potential threats to the assets.

(5) Combine associated potential threats, assets subject to loss, and
lack of mitigating controls; each triple of items constitutes a
vulnerability.

(6) Evaluate and rank the vulnerabilities in terms of greatest to least
expected potential loss; alternatively quantify risk for all or only
the major vulnerabilities in terms of annual frequency of loss and
single case loss in dollars to obtain annualized loss exposure.

(7) Identify actions and controls that would reduce the risks of losses
to acceptably low levels.

(8) Recommend an implementation plan to reduce risk to an overall
acceptably low level.

(9) Carry out the plan and establish ongoing security maintenance and
improvements.

Several steps may be combined or overlapped for task group operating
efficiency. Various methods such as use of questionnaires and loss and
frequency data forms or scenarios can aid in accomplishing the tasks and
documenting the results. Some steps may involve a high volume of data to
warrant use of computer-aided methods. For example, quantified risk
assessment requires expected frequency of loss and dollar value of single
incident loss from both intentional and accidental modification,
destruction, disclosure, use and denial of use (for various periods of
time) for all computer-related threats and assets.

In practice, however, the formalized review approach is rarely taken, or
only severely limited versions are adopted. More likely, only piecemeal
discoveries of vulnerabilities and their solutions happen. These events
are occasioned by other information processing activities such as audits,
loss events, new applications, new or newly enforced requirements,
contracting, or budget studies. If a specific study is conducted, often
obvious, significant vulnerabilities are identified early and actions
taken to reduce their risk even before the final recommendations are made.

$SECUIRTY METHODS IN PRACTICE

A survey of management practices was conducted at the seven field sites.Managers
were asked to describe the process curretnly used to select, justify, and
install computer security controls. Both methodology and organizational factors
were studied. Three typical case studies for a government agency, a research
organization, and a private sector firm are included in Appendix A.

None of the organizations studied used a formal cost-benifit or risk analysis to
evaluate computer security controls. These techniques, which have been heralded
in the literature, were thought to be excesively elaborate and not
cost-effective. Quantitative analyses were considered not appropriate because
of a lack of valid data. Instead, each site primarily used subjective and
somewhat informal piecemeal techniques for assessing the pros and cons of
particular computer security controls.

These subjective techniques can be described as the exercise of prudent care or
subscribing to generally used controls. the words "prudence" and "common sense"
were frequently used in describing what went into these subjective assessment
approaches. Generally used approaches were defined in terms of the practices of
other organizations in similar environments. Management essentially asked, "If
another manager were in my place, would he install and operate the proposed
control?" Factors considered in answering this questing include:

: The controls actually being used by other orgainziations with similar
applications and equipment.

: Reported loss experience.

: The perceived needs of the organization's own operating environment
compared to other organizations with similar environments.

: The increased level of security to be achieved.

: Laws and regulations.

Definitions of generally used controls typically consider a wideranging
control environment. Policies and professional ethical mores, personnel
procedures, and manual procedures can be used to make up for the possible
lack of computer-based controls, especially in computer systems where
security has not been a design and implementation criterion.

Another important factor in the decision to use a particular control was the
influence of outside parties. Clients served by the organizations specified
requirements that had to be met before certain work could be performed and
data could be obtained. these requirements mirrored requirements that in
some instances came from within the organization. External and internal
auditors were other sources of relevant information. Quantitative
information such as the cost to install and operate a control, money to be
saved, or the losses to be prevented ( from catastrophes, lawsuits, or
public embarrassment ) were rarely considered.

Management in most cases did not actively seek information about what is
done elsewhere. Although they used this information when made available to
them and found it to be of great interest and potentially useful, they did
not believe that contacting similar organizations and asking questions were
cost-effective. The exception to this occurred when very costly controls,
such as vaults or electronic lock access systems, were considered.
Management then directed technical personnel to study alternative products
and survey users of the products. Sometimes prioritized lists of desirable
controls were prepared as wish lilsts that could be reviewed whenever
budgets were prepared. The lists were helpful in matching high-priority
controls with limited resources. Controls were viewed as necessary
resource-consuming items rather than revenue generating or cost-saving
items. The time frame was typically 3 to 5 years.

The source of the funds to be used for a control largely dictated the
approval process; if funds were to come from a government grant, from
organizational overhead, or from a client project, then the approval
channels were markedly different in each case. The approvoal process also
varied depending on the time of year when the need for a control was
noticed. If a need was perceived shortly before budgets were prepared, and
installation could be delayed until the next fiscal year, then it was
included in the budget. If installation of a control could not be delayed
until the next fiscal year, then it was included in the budget. If
installation of a control could not be delayed until the next fiscal year,
special procedures were requried to rearrange currently budgeted funds to
obtain additional funds.

Documentation of the decision process was often sparce. Purchase
requisitions and budgets on the proposed control were sometimes the only
formal documents produced. Explicit management approval in these cases was
given when these forms were approved. Larger organization werre more liekly
to require formal documentation that included proposals, signoff sheets,
memos, impact statements, and in rare instances cost-benefit analyses.
Systems development and modification methodologies in some cases included
requirements for considering computer security. Security was reviewed when
a system was designed, redesigned, or modified, but not otherwise. The
concern for security was not dealt with in isolation from other activites.
Typically, a control that was retroisolation from other activites.
Typically, a control that was retrofitted to an existing system was
evaluated in the same manner as a control that was originally designed into
a system. Both were subject to the system development and modification
methodology.

Documentation of control decisions and the resulting changes to be made were
more extensive whenever a control was going to affect people outside the
organization. One organization wrote and maintained a specialized secure
operating system; another developed and installed a security program
package. For these products, strict requirements for system change
justification and documentation existed.

$DECISION-MAKING FACTORS

Typically, the decision to adopt a control was made by the line managers
from the area primarily involved; for example, if an electronic lock access
system would restrict the activities of computer operators, then compuer
operations management would make the decision.

In some instances, security committees that had an advisory role in the
decision to adopt computer security controls were formed. These committees
were composed of higher level managers who represented the following
organizational ares: The legal department, user organizations, applications
development, computer operations, and industrial security. These committees
monitored legal and regulatory requirements , current events, and the
current security systems. In rare cases, the committee had approval
authority.

When a proposed control affected several parts of the organization in a
significant monetary or operational way, then management approval of each of
these areas was usually obtained. Approval by industrial security, legal
counsel, audit, personnel, users, as well as other departments of a compute
center besides the one proposing a control was thus sometimes requred. For
example, if a control would increase the rates for computing services
charged to users, or if it would change the user's interaction with a
computer system, then the users would typically be involved in the decision
process. Occasionally, if many areas were involved, then a higher level
manager who had each of these areas reporting to him decided whether to
adopt a proposed control.

The computer service provider may play different roles in the identification
and approval of the need for a control. The service provider in some cases
was responisble for telling the user what was needed, while in other
organizations the user was responisble for telling the service provider what
was required. In either case, expertise within the computer sevice
provider's organization was relied on. In some organizations, other
departments such as audit and legal counsel were supposed to alert involved
parties to the need for additional controls, but the approval of the changes
still rested with the service provider and the user.

Audit departments were seldom involved in the control requirements and
specification process. Although many authors of computer security works
advocate that auditors be involved in systems design work, this
participation did not generally occur. Some say that this sytem is
adequate--auditors are not supposed to directly participate, which
specification of controls would imply. Auditors were said to only
infrequently review computer controls. Others state that auditors should be
more active in the review of controls, informing management of the need for
improvements. Larger organizations were more likely to have auditing staff
involved in these activities.

Many installations have noted that finding security experts in the computer
field to hire is a problem. In some cases controls were not evaluated or
implemented because of the lack of qualified personnel. the shortage of
experts in the computer security field is particularly acute.

Evidence of the maturing of computer security and the findings from
experience about selection of controls provide the background to consider
the motivation and need for adopting generally used controls. The next
section provides two specific examples of common sources of this motivation
and need and how they may be satisfied by generally used controls.

This section has described the increased recognition of the ned for security
controls and the maturation and status of the process of control selection.
a major factor relevant to decision making regarding computer security is
the legal framework surrondin data and releated computer violations and
liabilities. These issues are addressed in the next section.

$EOF

[OTHER WORLD BBS]



← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT