Security Principles: 27/sp800-27 PDF

Security Principles
There are many general security principles which you should be familiar with; one
good place for general information on information security is the Information
Assurance Technical Framework (IATF) [NSA 2000]. NIST has identified high-level
``generally accepted principles and practices'' [Swanson 1996]. You could also look at
a general textbook on computer security, such as [Pfleeger 1997]. NIST Special
Publication 800-27 describes a number of good engineering principles (although,
since they're abstract, they're insufficient for actually building secure programs hence this book); you can get a copy at http://csrc.nist.gov/publications/nistpubs/80027/sp800-27.pdf. A few security principles are summarized here.
Often computer security objectives (or goals) are described in terms of three overall
objectives:
Confidentiality (also known as secrecy), meaning that the computing system's
assets can be read only by authorized parties.
Integrity, meaning that the assets can only be modified or deleted by authorized
parties in authorized ways.
Availability, meaning that the assets are accessible to the authorized parties in a
timely manner (as determined by the systems requirements). The failure to
meet this goal is called a denial of service.
Some people define additional major security objectives, while others lump those
additional goals as special cases of these three. For example, some separately identify
non-repudiation as an objective; this is the ability to ``prove'' that a sender sent or
receiver received a message (or both), even if the sender or receiver wishes to deny it
later. Privacy is sometimes addressed separately from confidentiality; some define this
as protecting the confidentiality of a user (e.g., their identity) instead of the data. Most
objectives require identification and authentication, which is sometimes listed as a
separate objective. Often auditing (also called accountability) is identified as a
desirable security objective. Sometimes `àccess control'' and `àuthenticity'' are listed
separately as well. For example, The U.S. Department of Defense (DoD), in DoD
directive 3600.1 defines `ìnformation assurance'' as `ìnformation operations (IO) that
protect and defend information and information systems by ensuring their availability,
integrity, authentication, confidentiality, and nonrepudiation. This includes providing
for restoration of information systems by incorporating protection, detection, and
reaction capabilities.''
In any case, it is important to identify your program's overall security objectives, no

matter how you group them together, so that you'll know when you've met them.
Sometimes these objectives are a response to a known set of threats, and sometimes
some of these objectives are required by law. For example, for U.S. banks and other
financial institutions, there's a new privacy law called the ``Gramm-Leach-Bliley''
(GLB) Act. This law mandates disclosure of personal information shared and means
of securing that data, requires disclosure of personal information that will be shared
with third parties, and directs institutions to give customers a chance to opt out of data
sharing. [Jones 2000]
There is sometimes conflict between security and some other general system/software
engineering principles. Security can sometimes interfere with `èase of use'', for
example, installing a secure configuration may take more effort than a ``trivial''
installation that works but is insecure. Often, this apparent conflict can be resolved,
for example, by re-thinking a problem it's often possible to make a secure system also
easy to use. There's also sometimes a conflict between security and abstraction
(information hiding); for example, some high-level library routines may be
implemented securely or not, but their specifications won't tell you. In the end, if your
application must be secure, you must do things yourself if you can't be sure otherwise
- yes, the library should be fixed, but it's your users who will be hurt by your poor
choice of library routines.
A good general security principle is ``defense in depth''; you should have numerous
defense mechanisms (``layers'') in place, designed so that an attacker has to defeat
multiple mechanisms to perform a successful attack.

Security Principles: 27/sp800-27 PDF

Uploaded by

Copyright:

Available Formats

Security Principles: 27/sp800-27 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Security Principles: 27/sp800-27 PDF

Uploaded by

Copyright:

Available Formats

Security Principles

In any case, it is important to identify your program's overall security objectives, no

You might also like