188 lines
4.1 KiB
HTML
188 lines
4.1 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Security Environment and Objectives</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="Security Requirements"
|
|
HREF="requirements.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Common Criteria Introduction"
|
|
HREF="x595.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Security Functionality Requirements"
|
|
HREF="x615.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="x595.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 4. Security Requirements</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x615.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN608"
|
|
></A
|
|
>4.2. Security Environment and Objectives</H1
|
|
><P
|
|
>The first step in defining a PP or ST is identify the
|
|
``security environment''.
|
|
This means that you have to consider the physical environment
|
|
(can attackers access the computer hardware?),
|
|
the assets requiring protection (files, databases, authorization
|
|
credentials, and so on),
|
|
and the purpose of the TOE (what kind of product is it? what is
|
|
the intended use?).</P
|
|
><P
|
|
>In developing a PP or ST, you'd end up with a statement of
|
|
assumptions (who is trusted? is the network or platform benign?),
|
|
threats (that the system or its environment must counter),
|
|
and organizational security policies (that the system or its environment
|
|
must meet).
|
|
A threat is characterized in terms of a threat agent
|
|
(who might perform the attack?), a presumed attack method,
|
|
any vulnerabilities that are the basis for the attack, and what asset
|
|
is under attack.</P
|
|
><P
|
|
>You'd then define a set of security objectives for the system
|
|
and environment, and show that those objectives counter the threats
|
|
and satisfy the policies.
|
|
Even if you aren't creating a PP or ST, thinking about your assumptions,
|
|
threats, and possible policies can help you avoid foolish decisions.
|
|
For example, if the computer network you're using can be sniffed
|
|
(e.g., the Internet), then unencrypted passwords are a foolish idea
|
|
in most circumstances.</P
|
|
><P
|
|
>For the CC, you'd then identify the functional and assurance requirements
|
|
that would be met by the TOE, and which ones would be met by the environment,
|
|
to meet those security objectives.
|
|
These requirements would be selected from the ``chinese menu'' of the CC's
|
|
possible requirements, and the next sections will briefly describe
|
|
the major classes of requirements.
|
|
In the CC, requirements are grouped into classes, which are subdivided into
|
|
families, which are further subdivided into components; the details of all this
|
|
are in the CC itself if you need to know about this.
|
|
A good diagram showing how this works is in the CC part 1, figure 4.5,
|
|
which I cannot reproduce here.</P
|
|
><P
|
|
>Again, if you're not intending for your product to undergo a CC evaluation,
|
|
it's still good to briefly determine this kind of information and informally
|
|
write include that information
|
|
in your documentation (e.g., the man page or whatever your documentation is).</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="x595.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="x615.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Common Criteria Introduction</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="requirements.html"
|
|
ACCESSKEY="U"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Security Functionality Requirements</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |