Re: Important Comments re: INtrusion Detection

[mcnabb () argus-systems com (Paul McNabb)]

>  Date: Sun, 15 Feb 1998 23:56:34 +0000
>  To: Darren Reed <darrenr () cyber com au>
>  From: "Steven M. Bellovin" <smb () research att com>
>  
>  Yes, but -- or, more properly, *BUT*.  A "secure" operating system --
>  and I suspect that you used quotes for the same reason I did -- would
>  indeed help.  *BUT* we need a new definition of security.
>  
>  I've never seen a formal definition of "security" for a UNIX system.
>  Informally, though, I'd say it's secure if a process operating as a
>  non-privileged user (and by that I mean not root, bin, lpr, uucp, daemon,
>  etc.) can obtain access to files that would not be permitted by a static
>  examination of the state of the file system at the start of the operation.
>  (There are lots of nits one can pick here, such as "what about the su
>  command?"  Please don't bother -- this is, as noted, an informal
>  definition.)
>  
>  "Orange Book" systems follow a formal model of security:  Bell-Lapadula.
>  It's arguable if that model is really useful in today's world; it's much
>  clearer that mandatory access controls don't add much to firewalls, and
>  probably not to intrusion detection systems.  
>  
>  Can one come up with a suitable definition?  I don't know.  I'm fairly sure,
>  though, that it's not a trivial problem to come up with a definition
>  that's both suitable and useful.  (By "useless", I mean something like
>  "ignores all packets with the EVIL bit set"...)

Actually, the old Orange Book model tried to define a level of security
plus what you need to do to verify that the product performed (assurance).
The European ITSEC and the new Common Criteria have an entirely different
approach.  The primary document for an evaluation is a required "Security
Target" document that describes 1) the threats you claim to counter, 2) the
features of your product that are used to eliminate or reduce the threat,
3) the environment you expect to run in (physical, legal, etc.), and 4) any
assumptions you have made (e.g., physical security).  Everything in the
evaluation revolves around verifying the claims of the Security Target.

If you are looking at any product (crypto, network, OS, database, whole
system, etc.) that claims either an ITSEC or a CC certification, you can
request this document from the vendor.  If the Security Target claims that
the product counters certain denial of service, file system, authentication,
or network attacks, you can then see what mechanisms they claim to be
using and also how much the evaluators analyzed the documents and product
(including penetration testing).

These newer government certification procedures are much more flexible
and useful than the older Orange Book stuff, even though some of the
old terminology (C2, B1) is still in use.  Newer evaluations can claim
an Orange Book level if the security enforcing mechanisms in the Security
Target are a superset of the Orange Book level you are claiming to meet.

A *secure* Unix system would be one that meets your definition of
security in the Security Target defined for the system.  The CC has
a concept of a Protection Profile that can be used to define a generic
security definition that can be used as the basis for the claims of a
Security Target.  The guys have done a really good job here.  Check out
the definitions (particularly Part 2) in the Version 2.0 DRAFT (12/97).

     http://csrc.nist.gov/cc/info/infolist.htm

paul

---------------------------------------------------------
Paul McNabb                     Argus Systems Group, Inc.
Vice President and CTO          1809 Woodfield Drive
mcnabb () argus-systems com        Savoy, IL 61874 USA
TEL 217-355-6308
FAX 217-355-1433                "Securing the Future"
---------------------------------------------------------