255 lines
6.4 KiB
HTML
255 lines
6.4 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Security Principles</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="Secure Programming for Linux and Unix HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Background"
|
|
HREF="background.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="History of Unix, Linux, and Open Source / Free Software"
|
|
HREF="history.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Why do Programmers Write Insecure Code?"
|
|
HREF="why-write-insecure.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Secure Programming for Linux and Unix HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="history.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 2. Background</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="why-write-insecure.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="SECURITY-PRINCIPLES"
|
|
></A
|
|
>2.2. Security Principles</H1
|
|
><P
|
|
>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
|
|
<A
|
|
HREF="http://csrc.nist.gov/publications/nistpubs/800-27/sp800-27.pdf"
|
|
TARGET="_top"
|
|
>http://csrc.nist.gov/publications/nistpubs/800-27/sp800-27.pdf</A
|
|
>.
|
|
A few security principles are summarized here.</P
|
|
><P
|
|
>Often computer security objectives (or goals) are described in terms of three
|
|
overall objectives:
|
|
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
><EM
|
|
>Confidentiality</EM
|
|
> (also known as secrecy), meaning that the
|
|
computing system's assets can be read only by authorized parties.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><EM
|
|
>Integrity</EM
|
|
>, meaning that the assets can only be modified or deleted by
|
|
authorized parties in authorized ways.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><EM
|
|
>Availability</EM
|
|
>,
|
|
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.</P
|
|
></LI
|
|
></UL
|
|
>
|
|
|
|
|
|
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
|
|
<EM
|
|
>user</EM
|
|
> (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 ``access control'' and ``authenticity'' are listed separately
|
|
as well.
|
|
For example,
|
|
The U.S. Department of Defense (DoD), in DoD directive 3600.1
|
|
defines ``information assurance'' as
|
|
``information 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.''</P
|
|
><P
|
|
>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.</P
|
|
><P
|
|
>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]</P
|
|
><P
|
|
>There is sometimes conflict between security and some other general
|
|
system/software engineering principles.
|
|
Security can sometimes interfere with ``ease 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.</P
|
|
><P
|
|
>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.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="history.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="why-write-insecure.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>History of Unix, Linux, and Open Source / Free Software</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="background.html"
|
|
ACCESSKEY="U"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Why do Programmers Write Insecure Code?</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |