247 lines
6.1 KiB
HTML
247 lines
6.1 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Security Assurance Measure Requirements</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="Security Functionality Requirements"
|
|
HREF="x615.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Validate All Input"
|
|
HREF="input.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="x615.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="input.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN641"
|
|
></A
|
|
>4.4. Security Assurance Measure Requirements</H1
|
|
><P
|
|
>As noted above, the CC has a set of possible assurance requirements that
|
|
can be selected, and several predefined sets of assurance requirements
|
|
(EAL levels 1 through 7).
|
|
Again, if you're actually going to go through a CC evaluation, you
|
|
should examine the CC documents; I'll skip describing the measures
|
|
involving reviewing official CC documents (evaluating PPs and STs).
|
|
Here are some assurance measures that can increase the confidence
|
|
others have in your software:
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>Configuration management (ACM).
|
|
At least, have unique a version identifier for each TOE release, so that
|
|
users will know what they have.
|
|
You gain more assurance if you have good automated tools to control
|
|
your software, and have separate version identifiers for each piece
|
|
(typical CM tools like CVS can do this, although CVS doesn't record
|
|
changes as atomic changes which is a weakness of it).
|
|
The more that's under configuration management, the better;
|
|
don't just control your code, but also control documentation,
|
|
track all problem reports (especially security-related ones),
|
|
and all development tools.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Delivery and operation (ADO).
|
|
Your delivery mechanism should ideally let users detect unauthorized
|
|
modifications to prevent someone else masquerading as the developer, and
|
|
even better, prevent modification in the first place.
|
|
You should provide documentation on how to securely install, generate,
|
|
and start-up the TOE, possibly generating a log describing how the TOE
|
|
was generated.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Development (ADV).
|
|
These CC requirements deal with documentation describing the TOE
|
|
implementation, and that they need to be consistent between each other
|
|
(e.g., the information in the ST, functional specification, high-level
|
|
design, low-level design, and code, as well as any models of the
|
|
security policy).</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Guidance documents (AGD).
|
|
Users and administrators of your product will probably need some
|
|
sort of guidance to help them use it correctly.
|
|
It doesn't need to be on paper; on-line help and "wizards" can help too.
|
|
The guidance should include warnings about actions that may be
|
|
a problem in a secure environemnt, and describe how to use the system
|
|
securely.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Life-cycle support (ALC).
|
|
This includes development security (securing the systems being used
|
|
for development, including physical security),
|
|
a flaw remediation process (to track and correct all security flaws),
|
|
and selecting development tools wisely.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Tests (ATE).
|
|
Simply testing can help, but remember that you need to test the
|
|
security functions and not just general functions.
|
|
You should check if something is set to permit, it's permitted, and
|
|
if it's forbidden, it is no longer permitted.
|
|
Of course, there may be clever ways to subvert this, which is what
|
|
vulnerability assessment is all about (described next).</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Vulnerability Assessment (AVA).
|
|
Doing a vulnerability analysis is useful, where
|
|
someone pretends to be an attacker and tries to find vulnerabilities
|
|
in the product using the available information, including documentation
|
|
(look for "don't do X" statements and see if an attacker could exploit them)
|
|
and publicly known past vulnerabilities of this or similar products.
|
|
This book describes various ways of countering known vulnerabilities of
|
|
previous products to problems such as replay attacks (where known-good
|
|
information is stored and retransmitted), buffer overflow attacks,
|
|
race conditions, and other issues that the rest of this book describes.
|
|
The user and administrator guidance documents should be examined to
|
|
ensure that misleading, unreasonable, or conflicting guidance is
|
|
removed, and that secrity procedures for all modes of operation
|
|
have been addressed.
|
|
Specialized systems may need to worry about covert channels;
|
|
read the CC if you wish to learn more about covert channels.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Maintenance of assurance (AMA).
|
|
If you're not going through a CC evaluation, you don't need a formal
|
|
AMA process, but all software undergoes change.
|
|
What is your process to give all your users strong confidence that future
|
|
changes to your software will not create new vulnerabilities?
|
|
For example, you could
|
|
establish a process where multiple people review any proposed changes.</P
|
|
></LI
|
|
></UL
|
|
></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="x615.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="input.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Security Functionality Requirements</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="requirements.html"
|
|
ACCESSKEY="U"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Validate All Input</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |