|
Generally Accepted System Security Principles (GASSP)
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
********************* EXPOSURE DRAFT
********************
OF THE
GENERALLY ACCEPTED SYSTEM SECURITY
PRINCIPLES (GSSP)
****************************************************
*******
Note: When converting this document, the three Figures were not
able to be reproduced. For a hard copy, please contact
Kathleen Harvey, 600 Delran Parkway, Delran, NJ 08075 or e-
mail
at: [email protected]
Datapro Summary
The National Research Council's Computers at Risk report
recommended the development of a comprehensive set of
Generally
Accepted System Security Principles (GSSP) which could be
used as
a basis for resolving differences between U.S. and foreign
criteria for trustworthy systems and as a vehicle for shaping
input to international discussions of security and safety
standards. This Exposure Draft represents the first edition;
providing the background, framework, and pervasive principles of
the GSSP.
Author
Prepared by the GSSP Draft Sub-committee
August 18, 1994
Volume 1: Background, Framework and Pervasive Principles
Background
In 1990, the National Research Council published Computers at
Risk(1) (CAR), a landmark book that emphasized the urgent need
for
the nation to focus attention on information security. The GSSP
document is a direct result of recommendation number one from
CAR
(see Appendix A for CAR recommendation details).
Recommendation 1 -- Promulgation of a comprehensive set of
Generally Accepted System Security Principles, referred to as
GSSP, which would provide a clear articulation of essential
features, assurances, and practices.
The CAR report proposes the Generally Accepted Accounting
Practices
as a model for GSSP. It cites the Building Code and the
Underwriter's Laboratory as examples of GSSP in other fields. It
also recommends building on the experience captured by using
the
TCSEC, the TNI, and the ITSEC documents to create a broader
set of
criteria that will drive a more flexible process for evaluating
single-vendor and conglomerate systems.
Securing today's automated information systems and protecting
information assets is a product of an iteration of processes.
These processes are a progression of preventive, detective, and
corrective measures. Information gathering; designing, selecting,
or specifying safeguards; implementing safeguards; maintaining
and
administering safeguards; and estimating the value of information
assets and their potential for impact due to loss or compromise
are examples of preventive measures. Detective processes include
measuring the effectiveness of preventive steps; and monitoring,
recording, analyzing, responding to and reporting of events.
Finally, promoting solutions to developers, management, and
industry; training for security awareness and job-specific needs;
and responding to environmental changes (e.g., organizational,
threats, vulnerabilities, or new technologies) are examples of
corrective actions. The introduction of an accepted, uniform, code
of practice would strengthen these processes. Therefore, each of
these processes should be carried out in accordance with
generally
accepted system security principles.
Definition of Key Terms
Generally Accepted System Security Principles (GSSP)
Generally Accepted System Security Principles incorporate the
consensus at a particular time as to the practices, conventions,
rules, mechanisms, and procedures that 1) information security
professionals should employ, or that 2) information processing
products should provide, to achieve, preserve, and restore the
properties of integrity, availability, and confidentiality of
information and information systems.
GSSP is a technical security term encompassing the practices,
conventions, rules, mechanisms, and procedures that are needed
to
define accepted security practice at a particular time. It
includes broad guidelines and detailed practices and procedures.*
*<footnote>The Generally Accepted Accounting Principles
(GAAP) were
recommended by the Computers at Risk authors as an appropriate
model for GSSP. GAAP are defined as "A technical accounting
term
encompassing the conventions, rules, and procedures that are
needed to define accepted accounting practice at a particular
time. It includes broad guidelines and detailed practices and
procedures." from Page 6-3, Chapter 6, Part II A of "CPA
Review",
Nathan Bisk, JD, C.P.A., 1985. One significant difference that
been noted between proposed GSSP and GAAP: GAAP define
conventions, rules, standards, and procedures that are needed to
define accepted security practice for Accounting professionals
only. In addition to defining the conventions, rules, standards,
and procedures for information security professionals, GSSP
define
required countermeasures and practices to be included in vendor
security products.<endfootnote>.
Generally Accepted
GSSP are conventional--that is, they become generally accepted
by
agreement (often tacit agreement) rather than formal derivation
from a set of postulates or basic concepts. The principles have
been developed on the basis of experience, reason, custom, usage,
and, to a significant extent, practical necessity. The sources of
established security principles are generally the following:
* Pronouncements of an authoritative body (to be established)
designated by the ISSA Board of Directors and others as
appropriate, to establish security principles.
* Pronouncements of bodies composed of expert security
professionals that follow a due process procedure, including
broad
distribution of proposed security principles for public comment,
for the intended purpose of establishing security principles or
describing existing practices that are generally accepted. Includes
Security Audit guides and Statements of Position.
* Practices or pronouncements that are widely accepted as being
generally accepted because they represent prevalent practice in a
particular industry or the knowledgeable application to specific
circumstances of pronouncements that are generally accepted.
Includes interpretations and practices that are widely recognized
and prevalent in the industry.
* Other security literature. Includes pronouncements of other
professional associations or regulatory agencies, and information
security textbooks and articles.
The concept of generally accepted is to be distinguished from the
concept of universally accepted. This distinction has been made
to
address the case that even obvious fundamental principles, such
as
accountability, may have exceptions (e.g., a library system that
insists that use of the card catalog system have no accountability
to preserve the privacy of the user). Since situations outside of
the GSSP may be considered appropriate exceptions, it will be
necessary to include a procedure to follow when an information
security professional deems it necessary to depart from the
published GSSP.
System
For this report, the term System is used as an umbrella term for
the hardware, software, physical, procedural, and organizational
(sometimes referred to as physical, administrative, personnel, and
technological security) issues that need to be considered when
addressing the security of an application, group of applications,
organization, or group of organizations. It is used to imply that
these principles address the broadest definition of security
rather than just the security operations discipline. The term is
intended to be the equivalent of the terms Information Technology
(IT) and Automated Information System (AIS), Automated Data
Processing Element (ADPE), etc.
Security Principles
For this report, the term Security Principles is used in its
broadest application. At least initially, it is beneficial to
include generally accepted principles, practices, policies,
standards, and categories of procedures without distinction. Three
useful, albeit somewhat arbitrary categories will be used to
collect, discuss, and organize security principles: pervasive
principles, broad operating/functional principles, and detailed
security principles. The broad operating/functional principles and
detailed security principles will be divided into principles for
information security professionals and principles for information
processing products. In addition, the broad operating/functional
principles and the detailed security principles will be organized
and presented twice, once organized along operations lines and
once
organized along functional lines.
GSSP will be used to support security professional certification,
external audit, security product development, and maintain
credibility with management. To meet these needs, GSSP must
have
substantial authoritative support. Opinions of the Security
Principles Board have substantial authoritative support (by
design). Substantial authoritative support can exist for
principles that differ from opinions of the Security Principles
Board.
Framework
Security Principles Boards
GSSP governing practices of Certified Information System
Security
Professionals and external audit will be governed by an opinion
board consisting of respected members of the information security
profession, nominated by executive committee and elected by a
council. The relationship between Certification, GSSP, the
Security
Principles Board, and the Common Body of Knowledge is
illustrated
in Figure 1. The board will have practitioners, industrialists,
educators, and government employees. The board will:
* Publish proposed and approved opinions of the profession
about
accepted practices, processes, standards, and professional codes
of conduct.
* Establish a process for gathering comments about proposed
opinions and determining whether proposed opinions merit
inclusion
in the GSSP as an opinion of the profession and finally
incorporating those with demonstrable consensus as Generally
Accepted System Security Principles.
* Establish processes for reporting and dispositioning acts by
professionals not in accordance with GSSP (to include loss of
certification, censure, etc.).
* Establish processes for professionals to depart from
GSSP-authorized exceptions-- without censure or loss of
certification.
A similar board will be established to publish proposed and
approved opinions of the profession regarding principles,
practices, standards, and processes to be included or adhered to
in security products. These principles could also be supported by
a product certification process (manifested by a registered
trademark or a Common Criteria* registered protection profile)
and
periodic audits of product compliance to GSSP. See Figure
"Relationship of GSSP to Information Systems Security."
*<footnote>The Common Criteria is a document and process that
is
being built by NIST, NSA, and international organizations to
build
protection profiles that may be used by vendors to create security
products that meet those organizations' needs. The process of
building a profile includes a step for specifying evaluation
criteria. If the GSSP could be expressed as a protection profile,
then it would inherit a global distribution and evaluation
channel. Couple this with an admonition to Certified Information
Systems Security Professionals to exercise preference for
applications that meet the GSSP profile. This approach could
accelerate the acceptance and proliferation of GSSP for vendor
security product offerings. Editor's note: The GSSP committee
has
received comments suggesting that a single board should publish
and maintain opinions on security practices, processes, standards,
and codes of behavior for professionals; and also publish and
maintain opinions regarding principles, practices, and processes
to be included or adhered to in security products. This issue will
be debated at an upcoming committee meeting.<endfootnote>
Principle Hierarchy
Candidate principles may be placed into one of the three
categories
of principles. The categories are defined as follows:
* Pervasive Principles relate to information security as a whole
and provide a basis for other principles.
* Broad Operating/Functional Principles guide the recording,
measuring, and communicating processes of information security.
* Detailed Security Principles indicate the practical
application of the pervasive and broad operating/functional
principles.
The pervasive principles are few in number and are fundamental in
nature and as such will change rarely. The broad operating
principles are derived from the pervasive principles and are more
numerous, more specific, and guide the application of a series of
more detailed principles. The detailed security principles are
numerous and specific. They are generally based on one or more
broad operating principles and the broad operating principles are
generally based on the pervasive principles.
Pervasive Principles
The pervasive principles specify the general approach information
security should take to establish, maintain, and report on the
security of systems in their charge. These principles also form
the basis for other principles. The properties of integrity,
availability, and confidentiality are the values that the
principles, practices, and procedures, et. al, are attempting to
attain, preserve, and monitor.
The pervasive principles are based largely on the work of the
Organization for Economic Cooperation and Development
(OECD).
Member states include the U.S., Canada, Australia, and Japan
(total of 24 member states). The OECD principles were modified
and
extended using works from the Authoritative Foundation,* GSSP
committee review and comment, and comments obtained in the
process
of obtaining information security professional consensus.
*<footnote>The Authoritative Foundation is a list of fundamental
works on security compiled by the GSSP committee to support
the
development of GSSP. The list is available from
ISSA.<endfnote>
P-1 Accountability Principle--Information system security
accountability and responsibility should be explicit.
Accountability characterizes the ability to ensure that the roles
and actions of all parties who interact with information are
clearly defined, identified, and authenticated at a level
commensurate with the sensitivity and criticality of information
systems and data. Accountability enables many safeguards.
Without
accountability, individual permissions and privileges cannot be
effectively enforced or audited. In cases where the specific
application requires user anonymity, (as in decision support
systems, voting, or library card catalog use) accurate data can be
provided to the user, while the useer's anoniminity is ensured,
without sacrificing the accountability and integerity of the data.
It is important that the responsibilities and accountability of
owners, providers, users of information systems, and other parties
concerned with the security of information systems (such as
custodians and auditors) be explicit. For example, the relationship
between users, processes, and data should be clearly defined. For
each system, the concepts and responsibilities of the information
owner, manager, custodian, steward, user, developer, security
official, auditor, and maintainer should be documented and taught
as a part of system and organization training.
P-2 Awareness Principle--Owners, providers, and users of
information systems and other parties should be informed about
(or
readily be able to gain appropriate knowledge of) the existence
and general extent of measures, practices, procedures, and
institutions for the security of information systems.
Awareness of security measures, practices, procedures, and
institutions strengthens existing controls, enables some security
mechanisms, and can reduce certain threats. For example, the use
of personnel badges is weakened if it is not exhaustively
enforced. If unbadged individuals go unchallenged, a vulnerability
has been introduced to the system.
Awareness also increases user acceptance of controls. Security
policies and procedures often conflict with normal daily practice.
Without user acceptance, the users themselves will pose a risk to
the information system by ignoring, bypassing, overcoming, or
simply by doing what feels more natural to do. Successful security
awareness renders secure practices as a part of each individual's
natural response.
The Principle of Awareness is bidirectional. By educating users,
information security professionals will hear legitimate complaints
about impediments and obstructions to productivity; and
unreasonable demands or expectations. The awareness principle
applies to unauthorized users as well as authorized. If every user,
authorized or unauthorized, is made aware of the organization's
position on unauthorized use, and the potential consequences of
unauthorized use, some potential unauthorized users will chose to
decline the opportunity.
P-3 Ethics Principle--Information systems and the security of
information systems should be provided and used in accordance
with
the information security professionals' Code of Ethical Conduct.
The Code of Ethical Conduct prescribes the relationships of
ethics,
morality, and information. As social norms for using IT systems
evolve, the Code of Ethical Conduct will change and information
security professionals will spread the new concepts throughout
their organizations and products. Safeguards may require an
ethical
judgment for use or to determine limits or controls. For example,
entrapment is a process for luring someone into performing an
illegal or abusive act. As a security safeguard, a security
professional might set up an easy-to-compromise hole in the
access
control system, then monitor attempts to exploit the hole. This
form of entrapment is useful in providing warning that
penetration
has occurred. It may also provide enough information to identify
the perpetrator. Due to laws, regulations, or ethical standards,
it may be unethical to use data collected via entrapment in
prosecution, but it may be ethical to use entrapment as a detection
and prevention strategy. Legal and ethics advice should be sought.
P-4 Multidisciplinary Principle--Measures, practices, and
procedures for the security of information systems should address
all relevant considerations and viewpoints, including technical
(e.g., software and system engineering), administrative,
organizational, operational, commercial, educational, and legal.
Security is achieved by the combined efforts of data owners,
custodians, and security personnel. Essential properties of
security cannot be built-in and preserved without other
disciplines such as configuration management and quality
assurance.
Decisions made with due consideration of all relevant viewpoints
will be better decisions and receive better acceptance. If all
perspectives are represented when employing the least privilege
concept, the potential for accidental exclusion of a needed
capability will be reduced. This principle also acknowledges that
information systems are used for different purposes.
Consequently,
the principles will be interpreted over a wide range of potential
implementations. Groups will have differing perspectives,
differing
requirements, and differing resources to be consulted and
combined
to produce an optimal level of security for their information
systems.
P-5 Proportionality Principle--Security levels, costs, measures,
practices, and procedures should be appropriate and
proportionate
to the value of and degree of reliance on the information systems
and to the severity, probability, and extent of the potential for
direct and indirect harm. The principle also applies to the level
of management support necessary for a successful security
program.
The requirements for security vary, depending upon the particular
information system and the environment in which it operates.
This
principle supports approaches to security ranging from minimum
controls or baseline requirements to security based on managed
risk. Some organizations determine security measures based on an
examination of the risks, associated threats, vulnerabilities, loss
exposure, and risk mitigation through cost/benefit analysis using
a Risk Management Framework (see Figure "IT Security Risk
Management Framework").
Other organizations implement security measures based on a
prudent
assessment of "due care" (such as the use of reasonable
safeguards
based on the practices of similar organizations), resource
limitations, and priorities. The approach used and the degree it
is applied will be determined by the culture of the organization.
A control or safeguard has greater value if it performs more than
its primary function; e.g., deterrence, detection, prevention, and
recovery. Successfully activated safeguards will mitigate targeted
vulnerabilities and their associated threats, with an appropriate
balance of automated and human response.
P-6 Integration Principle--Measures, practices, and procedures for
the security of information systems should be coordinated and
integrated with each other and with other measures, practices, and
procedures of the organization so as to create a coherent system
of security.
The most effective safeguards are not recommended individually,
but
rather are considered as a component of an integrated system of
controls. In addition, most safeguards can be implemented as one
of 14 protection strategies.2 See Figure "Protection Strategy
Timeline."
Using these strategies, an information security professional may
prescribe preferred and alternative responses to each threat based
on the protection needed or budget available. This model also
allows the developer to attempt to place controls at the last
point before the loss becomes unacceptable. Since developers will
never have true closure on specification or testing, this model
prompts the information security professional to provide layers of
related safeguards for significant threats. Thus if one control is
compromised, other controls provide a safety net to limit or
prevent the loss. To be effective, controls should be applied
universally. For example, if only visitors are required to wear
badges, then a visitor could look like an employee simply by
removing the badge.
P-7 Timeliness Principle--Public and private parties, at both
national and international levels, should act in a timely
coordinated manner to prevent and to respond to breaches of the
security of information systems.
Due to the interconnected and transborder nature of information
systems and the potential for damage to systems to occur rapidly,
organizations may need to act together swiftly to meet challenges
to the security of information systems. In addition, international
and many national bodies require organizations to respond in a
timely manner to requests by individuals for corrections of
privacy data. This principle recognizes the need for the public
and private sectors to establish mechanisms and procedures for
rapid and effective incident reporting, handling, and response.
This principle also recognizes the need for information security
principles to use current, certifiable threat and vulnerability
information when making risk decisions, and current certifiable
safeguard implementation and availability information when
making
risk reduction decisions.
For example, an information system may also have a requirement
for
rapid and effective incident reporting, handling, and response. In
an information system, this may take the form of time limits for
reset and recovery after a failure or disaster. Each component of
a continuity plan, continuity of operations plans, and disaster
recovery plan should have timeliness as a criteria. These criteria
should include provisions for the impact the event (e.g.,
disaster) may have on resource availability and the ability to
respond in a timely manner.
P-8 Reassessment Principle--The security of information systems
should be reassessed periodically.
Information systems and the requirements for their security vary
over time. One of six events may trigger the need for an
information system to be reassessed:
* a significant change to the information system
* a significant change to the threat population
* a significant change to available safeguards
* a significant change in the users
* a significant change in the potential loss of the system
* a reasonable length of time (related to the potential for loss
of the information system) has elapsed such that accumulated
change may be significant.
P-9 Democracy Principle--The security of an information system
should be weighed against the rights of users and other
individuals affected by the system.
It is important that the security of information systems is
compatible with the legitimate use and flow of data and
information in the context of the host society. It is appropriate
that the nature and amount of data that can be collected is
balanced by the nature and amount of data that should be
collected. It is also important that the accuracy of collected
data is assured in accordance with the amount of damage that may
occur due to its corruption. For example, individuals' privacy
should be protected against the power of computer matching.
Public
and private information should be explicitly identified.
Organization policy on monitoring information systems should be
documented to limit organizational liability, to reduce potential
for abuse, and to permit prosecution when abuse is detected. The
monitoring of information and individuals should be performed
within a system of internal controls to prevent abuse.
Note: The authority for the following candidate principles has not
been established by committee consensus, nor are they derived
from
the OECD principles. These principles are submitted for
consideration as additional pervasive principles.
P-10 Certification and Accreditation Principle--Information
systems
and information security professionals should be certified to be
technically competent and management should approve them for
operations.
For information systems, certification is a determination by the
technical community that the integrity of a system is preserved;
all laws, regulations, and directives have been met; and that all
safeguards are in place and functioning correctly. Since these
conditions are never completely met, certification is accompanied
by a list of deficiencies for which the risk is acceptable and a
set of plans for resolving unacceptable risk. Certifiers should
attempt to accumulate a body of knowledge concerning
nondevelopmental software.* An objective of certification is to
give management confidence that the system can be accredited for
use. Note that this confidence may need to be re-established
following a security breach, or prior to the use of an alternate
site during disaster recovery.
Another objective of certifying a system is to ensure that the
system provides accurate logical representations of the physical
or logical objects it models. In some cases, such as when the
object is a person, the responsibility may be legislated, as it is
for privacy. For other objects, it may be good software
engineering practice or engineering needs that motivates the
requirement. The degree to which measures should be taken to
create, preserve, monitor, and recover an accurate representation
should be in accordance with the proportionality principle (P-5).
For information security professionals, job specific certification
(not to be confused with a professional certification like CISSP)
is a determination by Information Technology management that
the
individual has appropriate expertise, training, or background to
perform the assigned information security tasks. This could range
from Certified Information System Security Professional (CISSP)
certification with a background investigation for information
security managers to a prescription of required training for a
standalone workstation system administrator. The degree of
certification required should vary with the potential for loss of
the applicable system.
Accreditation acknowledges that management ultimately decides
whether the risk of certification deficiencies is at an acceptable
level to permit the individual to begin work or the information
system to begin operation.
*<footnote>Nondevelopmental software is software that was not
developed by the current development organization. It includes
Commercial-Off-The-Shelf software, reuse software, adapted
software, previously developed software, shareware, public
domain
software, etc.<endfootnote>
P-11 Internal Control Principle--Information security forms the
core of an organization's information internal control system.
This principle originated in the financial arena but has universal
applicability. As an internal control system, information security
organizations and safeguards should meet the standards applied
to
other internal control systems. "The internal control standards
define the minimum level of quality acceptable for internal
control systems in operation and constitute the criteria against
which systems are to be evaluated. These internal control
standards apply to all operations and administrative functions but
are not intended to limit or interfere with duly granted authority
related to development of legislation, rulemaking, or other
discretionary policymaking in an organization or agency.
A. General Standards
1. Reasonable Assurance. Internal control systems are to provide
reasonable assurance that the objectives of the systems will be
accomplished.
2. Supportive Attitude. Managers and employees are to maintain
and
demonstrate a positive and supportive attitude toward internal
controls at all times.
3. Competent Personnel. Managers and employees are to have
personal
and professional integrity and are to maintain a level of
competence that allows them to accomplish their assigned duties,
as well as understand the importance of developing and
implementing good internal controls.
4. Control Objectives. Internal control objectives are to be
identified or developed for each organizational activity and are
to be logical, applicable, and reasonably complete.
5. Control Techniques. Internal control techniques are to be
effective and efficient in accomplishing their internal control
objectives.
B. Specific Standards
1. Documentation. Internal control systems and all transactions
and
other significant events are to be clearly documented, and the
documentation is to be readily available for examination.
2. Recording of Transactions and Events. Transactions and other
significant events are to be promptly recorded and properly
classified.
3. Execution of Transactions and Events. Transactions and other
significant events are to be authorized and executed only by
persons acting within the scope of their authority.
4. Separation of Duties. Key duties and responsibilities in
authorizing, processing, recording, and reviewing transactions
should be separated among individuals.
5. Supervision. Qualified and continuous supervision is to be
provided to ensure that internal control objectives are achieved.
6. Access to and Accountability for Resources. Access to
resources
and records is to be limited to authorized individuals, and
accountability for the custody and use of resources is to be
assigned and maintained. Periodic comparison shall be made of
the
resources with the recorded accountability to determine whether
the
two agree. The frequency of the comparison shall be a function of
the vulnerability of the asset.
C. Audit Resolution Standard
Prompt Resolution of Audit Findings. Managers are to (1)
promptly
evaluate findings and recommendations reported by auditors, (2)
determine proper actions in response to audit findings and
recommendations, and (3) complete, within established time
frames,
all actions that correct or otherwise resolve the matters brought
to management's attention.3"
P-12 Adversary Principle--Controls, security strategies,
architectures, policies, standards, procedures, and guidelines
should be developed and implemented in anticipation of attack
from
intelligent, rational, and irrational adversaries with harmful
intent or harm from negligent or accidental actions.
Natural hazards may strike all susceptible assets. Adversaries will
threaten systems according to their own objectives. Information
security professionals, by anticipating the objectives of
potential adversaries and defending against those objectives, will
be more successful in preserving the integrity of information. It
is also the basis for the practice of assuming that any system or
interface that is not controlled is assumed to have been
compromised.
P-13 Least Privilege Principle--A individual should be granted
enough privilege to accomplish assigned tasks, but no more. This
principle should be applied in direct proportion and with
increased
rigor as the potential for damage to a system rises. For example,
on general-purpose systems, users may be divided into only two
groups, a small group of privileged users to perform system
administration and security and a larger group of normal users. On
mission- critical systems, the system may be segmented into small
groups, each with a well- defined role and access to group-specific
data and capabilities.
P-14 Separation of Duty Principle--Responsibilities and privileges
should be allocated in such a way that prevents an individual or
a small group of collaborating individuals from inappropriately
controlling multiple key aspects of a process and causing
unacceptable harm or loss.
This principle applies to many control circumstances. Segregation
can help to preserve the integrity, availability, and
confidentiality of information assets by minimizing opportunities
for security incidents, outages, and personnel problems.
P-15 Continuity Principle--Information security professionals
should identify their organization's needs for continuity of
operations and should prepare the organization and its
information
systems accordingly.
Organizations' needs for continuity may reflect legal, regulatory,
or financial obligations of the organization, organizational
goodwill, or obligations to customers, board of directors, and
owners. Understanding the organization's continuity requirements
will guide information security professionals in developing the
information security response to business interruption or disaster.
The objectives(4) of this principle are to ensure the continued
operation of the organization, to minimize recovery time in
response to business interruption or disaster, and to fulfill
relevant requirements.
The continuity principle may be applied in three basic concepts:
organizational recovery, continuity of operations, and end user
contingent operations. Organizational recovery is invoked
whenever
a primary operation site is no longer capable of sustaining
operations. Continuity of operations is invoked when operations
can
continue at the primary site but must respond to less than
desirable circumstances (such as resource limitations,
environmental hazards, or hardware or software failures). End
user
contingent operations are invoked in both organizational recovery
and continuity of operations.
P-16 Simplicity Principle--Information security professionals
should favor small and simple safeguards over large and complex
safeguards.
Simple safeguards can be thoroughly understood and tested.
Vulnerabilities can be more easily detected. Small, simple
safeguards are easier to protect than large, complex ones. It is
easier to gain user acceptance of a small, simple safeguard than a
large, complex safeguard.
P-17 Policy Centered Security Principle--Policies, standards, and
procedures should be established to serve as a basis for
management planning, control, and evaluation of information
security activities.
Communicating senior management policy directives to all
affected
individuals defines the relationship between information security
and other departments. The policy document conveys
management's
intent regarding information security concerns and describes the
organizational structure and associated responsibilities of
personnel who will be charged with implementing the policy.
Appendix A: Guidance from Computers at Risk
Major recommendations from Computers at Risk that are
addressed by
GSSP.
1. Promulgation of a comprehensive set of Generally Accepted
System
Security Principles, referred to as GSSP, which would provide a
clear articulation of essential features, assurances, and
practices.
2. A set of short-term actions for system vendors and users that
build on readily available capabilities and would yield immediate
benefits.
3. Directions for a comprehensive program of research.
4. Establishment of a new organization to nurture the
development,
commercialization, and proper use of trust technology, referred to
as the Information Security Foundation, or ISF.
Specific guidance from CAR for recommendation 1 and others
related
to GSSP is as follows:
1. Promulgate comprehensive Generally Accepted System Security
Principles (GSSP).
a. Establish a set of GSSP for computer systems.
b. Consider the system requirements specified by the Orange
Book for the C2 and B1 levels as a short-term definition of GSSP
and a starting point for more extensive definitions.
c. Establish methods, guidelines, and facilities for
evaluating products for conformance to GSSP.
d. Use GSSP as a basis for resolving differences between U.S.
and foreign criteria for trustworthy systems and as a vehicle for
shaping inputs to international discussions of security and safety
standards.
2. Take specific short-term actions that build on readily available
capabilities.
a. Develop security policies.
b. Use as a first step the Orange Book's C2 and B1 criteria.
c. Use sound methodology and modern technology to develop
high-quality software.
d. Implement emerging security standards and participate
actively in their design.
3. Establish an Information Security Foundation to address needs
that are not likely to be met adequately by existing entities.
a. Establishment of GSSP
b. Research on computer system security, including evaluation
techniques
c. System evaluation
d. Brokering and enhancing communications between
commercial
and national security interests
e. Focused participation in international standardization and
harmonization efforts for commercial security practice
Appendix B: Protection Strategies(2)
Safeguards may be categorized into protection strategies. At a high
level there are essentially three basic strategies: prevention,
detection, and recovery. It is useful to examine safeguards in
relation to their application along an incident event timeline.
Table 1 illustrates nine protection strategy types that can be used
to describe a safeguard.
TABLE 1
Protection Strategy Hierarchy
Prevention A Avoidance
T Transfer
RT Reduction of Threat
RV Reduction of Vulnerability
Detection RD Real-time Detection
NRD Non-real time detection
Recovery RI Reduction of Impact
RR Real-time Recovery
NRR Non real-time Recovery
The abbreviations are used as the legend to Figure 3. When
selecting safeguards, the information security professional may be
able to expand the range of available safeguards by envisioning an
available safeguard as each of the nine protection strategies.
Generally speaking, safeguards that operate prior to the event are
more effective and more expensive. Safeguards that operate after
the event are less expensive and less effective. Another
application of the diagram is as a graphical representation of the
coverage (by safeguards) of a system vulnerability. A detailed
explanation of each protection strategy follows:
1. Avoidance (A) is where the risk is bypassed. For example,
taking
a decision to no longer, or not to, process data; i.e., remove it
from the system under review and not process it by any other IT
system, or a physical asset is no longer to be used or is not to
be purchased.
2. Transfer (T) is where the asset or assets at risk is/are
transferred outside the boundary. For example, a highly sensitive
file could be removed and run on an entirely separate IT system,
thus transferring the risk to the other system. Alternatively, the
risk could be transferred outside the boundary, say by Insurance.
3. Reduction of Threat (RT) safeguards put a 'barrier', between the
threat (which might cause an action or event) and an asset. For
example, an RT safeguard could counter:
a. accidental threat to a physical asset, such as the
prohibiting of the storage of inflammable material near IT
equipment.
b. accidental threat to a data asset, such as better training
of staff to reduce people error.
c. deliberate internal threat, such as paying staff more money
to reduce the motivation for willful damage caused by
disgruntlement, or strictly enforced personnel disciplinary
procedures, or ensuring that non-security functions to be
performed
in the security administration role are limited to those essential
to performing that role effectively.
d. deliberate external threat, such as the removal of existing
or non-installation of dial-up lines, or the use of only private
circuits.
4. Reduction of Vulnerability (RV) safeguards make it more
difficult for a specific vulnerability to be exploited by a
threat. Examples of RV safeguards could include not installing
all
assets in the same physical location (thus reducing the
vulnerability to the loss of all the system assets, say in a major
fire), introducing dial- in protection, or plugging "loopholes" in
software. Thus individual RV safeguards reduce the level of a
specific weakness (or weaknesses), while in combination they will
make the system less vulnerable overall.
5. Reduction of Impact (RI) safeguards lessen the effect of an
impact on an asset, in particular to lessen the damage to assets.
Examples of an RI safeguard are daily backups of files for later
use in recovery, and the introduction of water sprinklers to
combat fire.
6. Real-time Detection (RD) safeguards detect the occurrence of
an
event as it happens, the conditions that indicate the potential
for an event exists, or evidence that an event has just occurred.
Examples of an RD safeguard include a smoke detector to detect
that
a fire may be present, software "sensors" to detect the attempted
use of network services that are not being offered, such as
potential intruders attempting to see if login is enabled. Both
real-time and non-real- time detection strategies are usually
coupled with one or more prevention or recovery strategies. In the
case of the smoke detector, the smoke detector may set off halon
to try to prevent the loss (RV), set off sprinklers to prevent
catastrophic loss (RI), or prevent loss of life by sounding audible
alarms (RT), automatically contact the fire department (RI),or any
combination of these. In the software example, the software
sensor
may send a message that triggers the system administrator's beeper
(RT), or it may send a message to a special log maintained on a
WORM CD drive to ensure an unmodifiable audit record of the
penetration attempt (NRR).
7. Real-time Recovery (RR) safeguards are related to the RI
safeguards. Both strategies involve reducing the impact of an
event. The RI strategy reduces damage to assets. The RR strategy
reduces the loss of service caused by the event. Examples are the
use of onsite stock of replacement parts, the use of
checkpointing*
*<footnote>Checkpointing is a technique where a system, in
real-time, stores critical application and environment data to
allow, when conditions permit, the system to be restarted without
having to power off the system and reinitialize all variables, a
procedure sometimes known as "cold start." Checkpointing can
also
be used to shorten the length of system start-up time following
a cold start by recording certain environment data and reducing
the user's burden by recording the user's configuration
data.<endfootnote>
and warm start to facilitate a quick return to service following a
system failure or system corruption, or the use of the well-formed
transaction, where an application restores itself to its previous
state when a transaction cannot be completed successfully. It also
includes the use of procedures to correct and validate corrupted
or erred data in real- time.
8. Non-Real-time Detection (NRD) safeguards discover the
manifestation of a threat which has exploited a vulnerability but
not during the occurrence of the event. Examples of NRD include
the analysis of audit trails, error logs, and traceability
journals. Other examples include EDP audits, cross-facility
analysis, and historical trend analysis.
9. Non-Real-time Recovery (NRR) safeguards attempt to return
the
system or data to a desired state after a failure or disaster has
occurred. NRR safeguards range from the procedures to recover a
user's deleted file to the ability (Disaster Recovery Plan) to
move to a remote location and successfully conduct operations
following a natural disaster.
10. Recording, while a form of the vulnerability reduction
protection strategy, is also an enabling mechanism for the
detection and recovery strategies. The choices made regarding
what
to record, when, and how often will dictate the degree of detection
and recovery possible. Examples of recording include electronic
data logging, handwritten operator logs, and video from
surveillance cameras.
You are invited to comment on this draft. Please forward your
reply
by January 31, 1995 to:
Will Ozier, GSSP Committee Chair OPA, Inc.
870 Market Street Suite 1001
San Francisco, CA 94102
or
send comments via Internet e-mail to: [email protected]
------------------------------------
References
1National Research Council, Dr. David Clark (MIT), committee
chair,
Computers at Risk, National Academy Press, 1991
2Robin Moses, BIS Applied Systems Limited and Ian Glover, UK
Central Computer and Telecommunications Agency, The CCTA
Risk
Analysis and Management Methodology (CRAMM)--Risk
Management Model,
from the Proceedings of the Second International Computer
Security
Risk Management Model Builders' Workshop, June 1989.
3Government Accounting Office, GAO Policy and Procedures
Manual for
Guidance of Federal Agencies--Title 2 Accounting
4Price Waterhouse for the Institute of Internal Auditors Research
Foundation, Systems Auditability and Control Module--
Contingency
Planning, Institute of Internal Auditors Research Foundation,
1991
Bibliography
Kabay, M.E. "Social Psychology and INFOSEC: Psychosocial
Factors in
the Implementation of Information Security Policy."
Ali Mosleh, University of Maryland, A Framework for Computer
Security Risk Management from Proceedings of the 3rd
International
Computer Security Risk Management Model Builders' Workshop,
sponsored by Los Alamos National Laboratory, NIST, and NCSC,
1989
Robin Moses, BIS Applied Systems Limited; Ian Glover, Ernst &
Young; and Len Watts, Central Computer & Telecommunications
Agency.
Updated Framework for Computer/Communications Security Risk
Management from Proceedings of the 3rd International Computer
Security Risk Management Model Builders' Workshop, sponsored
by Los
Alamos National Laboratory, NIST, and NSCS, 1990
Nathan Bisk, Jr. C.P.A., CPA Comprehensive Exam Review:
Auditing,
1985
Organisation for Economic Co-operation and Development
(OECD),
Guidelines for the Security of Information Systems, 1992
Donn Parker SRI, International, Information Security for
Applications in Distributed Computing from the Proceedings for
the
Second AIS Security Technology for Space Operations conference
(NASA/JSC Mission Operations Directorate and the Texas Gulf
Coast Chapter of the ISSA co-sponsors), 1993
Dr. Charlene A. Dykman, Control Objectives--Controls in an
Information Systems Environment: Objectives, Guidelines, and
Audit
Procedures, The EDP Auditors Foundation, Inc., 1992
Charles Cressen Wood, Information Integrity, Principles of Secure
Information Systems Design, Elsevier Science Publishers Ltd.,
1990
Zella G. Ruthberg and Harold F. Tipton editors, Handbook of
Information Security Management, Auerbach Publications, 1993
|
|
