Previous   Next   Top   Detailed TOC         Last Update: 08 mai 2002

21 Appendix C: Reference Material

• 21.0 List of Reference material with local copies
• 21.1 Security information: Where can I get it ?
  • A Quick guide for those in hurry!
  • Contacts & Links:
    • Virus Contacts
    • Response Teams
    • General security
    • Vendors
    • Firewalls
    • Security Hacking
    • Computer Underground
    • Other
• 21.2 Security Organisations
  • FIRST (Forum of Incident Response and Security Teams)
    • CERT
    • European Emergency Response Teams
    • AUSCERT
    • NASIRC (NASA Response Team)
    • CIAC (U.S. department of energy (DOE) Response Team) (June'96)
  • French Organisations (TBD)
  • U.S. Organisations/agencies
• 21.3 Internet Hacking Groups
• 21.4 Security standards
  • U.S. Standards: The Rainbow Books
  • The TCSEC "Orange Book"
    • Introduction
    • Contacts
    • 2.0 DIVISION C: DISCRETIONARY PROTECTION
  • The ITSEC - "European Orange Book"
    • Overview
    • Extract from the ITSEC Introduction
    • Contacts
    • Example functionality class F-DX
  • ITSEM (extracts)
  • TTAP
  • Common Criteria 1.0

NOTE: I keep a list of more recent references/links, updated on a weekly basis at www.boran.com/good_reads.html 

21.0 List of Reference material with local copies

The following documents are copied locally:

What if your Machines are Compromised by an Intruder Christopher Klaus of Internet Security Systems, Inc. <iss@iss.net>	compromise_faq.html
Tik-110.501 Seminar on Network Security Practical Cryptosystems and their Strength Janne Frösen Department of Computer Science Helsinki University of Technology Janne.Frosen@hut.fi     2.11.1995	CryptoAlgoStrength.html
Security evaluation standards ITSEC ITSEM TCSEC / Orange Book Common criteria (old version)	itsec.htm itsem.html tcsec.html commoncriteria.html
Security Mailing Lists FAQ, ISS	security_lists.html
Sniffer FAQ, ISS	sniff.html
Review of Policy relating to Encryption Technologies (The Walsh Report) Dec.1998 This file is the complete single-document version of the report. Original URL: http://www.efa.org.au/Issues/Crypto/Walsh/index.htm	walsh.zip
Cryptography and Liberty 1999 - An International Survey of Encryption Policy This is the best overview of international cryto policies I know of.	crytpo1999.htm.zip www2.epic.org/reports/crypto1999.html
Programming UNIX Programming tips, SunWorld. Code Signing: how-to	swol-unix-programming.html Doc_CodeSigning.html
System Administration Internet Webservers: best practices	webserver_practices.html
Don't forget human rights in all of this security stuff..... especially privacy aspects.	humanrights.html

21.1 Security information: Where can I get it ?

A list of books is available in the references section.

This sections contains lots of Internet references, plus description of security organisations and where possible Security Advisories released by them. The Internet is in a constant state of flux, so you may find that some of the links listed are no longer valid. In this case, use search engines such as Yahoo or Alta Vista (see below) to search for information.

21.1.1 A Quick guide for those in hurry!

• Searching for security information on the Internet: try
  www.SecurityPortal.com or  www.SecurityFocus.com  or  www.securitysearch.net ,
  the COAST archive coast.cs.purdue.edu/coast/coast.html, www.sans.org,  FIRST.
• To do a global search of the Internet for particular information try the usual search engines

Yahoo: www.yahoo.com          Alta Visa: www.altavista.com
Lycos: www.lycos.com           Google:     www.google.com

• Get yourself on the nearest FIRST mailing list (see www.first.org).
• Have a browse through the CERT, CIAC Advisories (see the titles below) to get a feel for what vulnerabilities are around.
• Each chapter is this book has a list of relevant reference material.

21.1.2 Contacts: Email lists, Response Teams, Vendors, Patch sources

Virus Contacts (oldish):

Newsgroup: comp.virus PC Viruses
PC Virus Info. mailto:listserv%lehiibm1.bitnet@mitvma.mit.edu
body= "SUB VIRUS-L myname@my.domain"
NCSA ftp://ftp.ncsa.com/pub/virus/WildList
Macro virus list ftp://ftp.informatik.uni-hamburg.de/pub/virus/macro/

Response Team Contacts:

FIRST mailto:first-sec@first.org
http://www.first.org [FIRST home page]

SWITCH CERT Switzerland mailto:cert-staff@switch.ch
CERT mailto:cert-advisory-request@cert.org *recommended*
CERT tools mailto:cert-tools-request@cert.org
ftp://cert.org/pub/cert_advisories
Other European Teams: see next section.
Australian CERT http://www.auscert.org.au/ [The Aussies are very up-to-date.]

CIAC mailto:ciac-listproc@llnl.gov subject=
"subscribe CIAC-ANNOUNCE Boran, Sean MY_PHONE_NR"
"subscribe CIAC-NOTES Boran, Sean MY_PHONE_NR"
"subscribe SPI-ANNOUNCE Boran, Sean MY_PHONE_NR"
"subscribe SPI -NOTES Boran, Sean MY_PHONE_NR"

General Security:

Risks forum mailto:risks-request@csl.sri.com
Best of Security (bos) mailto:majordomo@suburbia.net
Security mailing lists (local copy)
SANS Network Security Digest  mailto:sans@clark.net
     body='subscribe Network Security Digest your name'

Newsgroups General security news://comp.security.misc
                    Evils of technology news://comp.risks
                    Security Announcements news://comp.security.announce

ftp://ftp.switch.ch/mirror/security [lots of goodies in CH]
http://coast.cs.purdue.edu/homes/spaf/spafs_hotlist.html [Spafford's index of links: v.good]
http://www.tezcat.com/web/security/security_http.html [index to lots of network/Unix pages]

http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html [WWW server security]
http://www.primus.com/staff/paulp/cgi-security [broken] [WWW cgi scripts security]
http://hoohoo.ncsa.uiuc.edu/cgi/security.html [ as above]
IIS Security Configuration support.microsoft.com/support/kb/articles/Q229/6/94.asp

Vendor Contacts/patch sources:

Unix security mailto:security@cpd.com [not verified]

Sun:
Sun "Customer Warning System" Security alert mailto:security-alert@sun.com , subject="subscribe CWS myname@my.company.domain", Tel. +1 415 688-9081
Sun sysadmin mailto:sun-managers-request@eecs.nwu.edu
           body="add myname@ my.domain"
Security bulletins sunsolve.sun.com/sunsolve/secbulletins
Sun & java security   www.sun.com/security/index.html    
Newsgroup Solaris news://comp.unix.solaris     java.Sun.com/security
Patches
   Public  sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
   Patches sunsolve.sun.ch/pub-cgi/us/secbul.pl  
   Switzerland sunsolve.sun.ch   Contract patches sunsolve.sun.ch/private-cgi/us/patchpage.pl    
   Patch download tool WGET sunsite.auc.dk/ftp/pub/infosystems/wget/
   PatchDiag tool sunsolve.sun.ch/sunsolve/patchdiag

Precompiled freeware for Sun   www.sunfreeware.com
Solaris Guide index:  www.solarisguide.com
Sunworld sunwhere index of resources www.sunworld.com/sunworldonline/sunwhere.html
Jean Chouanard's Package for hardening Solaris ftp://ftp.parc.xerox.com/pub/jean/solins/solins.html
Jens Vöckler's script for tuning the Solaris TCP/IP stack (excellent for performance, security and learning ndd) http://www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html .

HP:
Hewlett Packard mailto:security-alert@hp.com
HP Security list mailto:support@support.mayfield.hp.com body="subscribe security_info"
HP-UX sysadmin mailto:majordome@cv.ruu.nl body="subscribe hpux-admin"
Newsgroup HP-UX news://comp.sys.hp.hpux

DEC:
mailto:rich.boren@cxo.mts.dec.com , Tel. +1 719 592-4689
OSF/1 sysadmin mailto:majordomo@ornl.gov body="subscribe alpha-osf-managers"
http://www.service.digital.com/html/patch_service.html

BSDI sysadmin bsdi-users-request@bsdi.com
SCO: security-alert@sco.com
Santa Cruz Operation ftp://ftp.sco.com/SLS
Linux: Linux Emergency Response Team:
http://bach.cis.temple.edu/linux/linux-security/Linux-Alerts/
www.redhat.com www.suse.com

Stampede GNU/Linux http://www.stampede.org/mailinglists.php3
Yellow Dog Linux and Black Lab Linux http://lists.yellowdoglinux.com
ESWARE Linux http://www.esware.com/actualizaciones.html
Kondara MNU/Linux http://www.kondara.org/errata/index.html.en
LinuxPPC http://www.linuxppc.com/support/updates/security

OpenBSD: www.openbsd.org

SGI/IRIX:
Email mailto:security-alert@sgi.com , Tel. +1 800 800-4SGI
Patches: Security advisories and patches from SGI can be obtained via ftp from ftp://sgigate.sgi.com or it's mirror ftp.sgi.com in the directory Security or Patches.

For issues relating to the above patches, refer to mailto:cse-security-alert@csd.sgi.com . For new issues, email mailto:security-alert@sgi.com

Newsgroup news://comp.sys.sgi.bugs (IRIX bugs).

IBM/AIX:
http://www.ers.ibm.com/tech-info
mailto:nrt@watson.ibm.com , Tel. +1 800 237-5511
ftp://software.watson.ibm.com/pub/aix3 [Some AIX security patches]
http://service.software.ibm.com/pbin-usa/fixdist.pl
http://service.software.ibm.com/aixsupport
http://www.ibm.com/security [Security Products & services]

NCR UNIX and MP-RAS UNIX http://www.ncr.com/support/support_drivers_patches.asp?Class=sys3000
UXP/V http://www.fujitsu.co.jp/hypertext/Products/Info_process/hpc/topics/cert/top/index-e.html

Microsoft/Windows NT:
NT Security Issues mailto:request-ntsecurity@iss.net
NTBugtraq mailto:listserv@listserv.ntbugtraq.com body= "SUB NTBUGTRAQ Your Name"
www.securityfocus.com
NT Security from ISS  mailto:request-ntsecurity@iss.net body="subscribe ntsecurity"
NT, Explorer security www.ntsecurity.net              *recommended*
Microsoft Security mailto:security@microsoft.com       www.microsoft.com/security
www.somarsoft.com/contents.htm [NT security]
www.iea.com/~daler/nt/faq/toc.html [NT frequently asked questions]

Cisco
www.cisco.com/warp/public/707/advisory.html
Article which explains different router password storage mechanisms & weakensses

For more lists of vendors, see http://razor.bindview.com/publish/papers/os-patch.html

Firewalls:

Firewalls mailto:majordomo@greatcircle.com "subscribe firewalls"
A digest is also available.

Security Hacking (full disclosure) groups:

Bug track discussion list mailto:bugtraq-request@fc.net
http://archives.neohapsis.com/archives/bugtraq

Bugtraq database securityfocus.com/vdb

A large portion of the hacking scene has gone "white hat" (read commercial), for example:

• @stake: http://stake.com/
• www.SecuriTeam.com

Currently inactive groups:

• 8lgm(8 legged groove machine or 8 Little Green Men): mailto:majordomo@8lgm.org body="subscribe 8lgm"    www.8lgm.org (This group was active during the mid 90s, advisories were quite good).
• Avalon mailto:mcpheea@cadvision.com

Computer Underground:

The following is a sample list of links to underground sites, they'll give an idea of how Internet Hackers think and what kind of information to start from.

www.insecure.org    The home for nmap, among other things
www.nessus.org      An interesting scanner
www.rootshell.com  Collection of tools
www.l0pht.com  NT password cracking & NFR plug-ins
www.atstake.com

www-personal.engin.umich.edu/~jgotts/underground/hack-faq.html The alt.2600/#hack FAQ Intro.
scitsc.wlv.ac.uk/~cs6171/hack/index.html Unix / net / hack page
scitsc.wlv.ac.uk/~cs6171/phrack/phrackindex.html Phrack
mailto:phrack@well.sf.ca.us Phrack
www.unix.geek.net/~arny Unix /net /hack page US mirror
www.paranoia.com/~coldfire/index.html Cold Fire's Web Page
www.2600.com  2600 Magazine
www-personal.engin.umich.edu/~jgotts/underground.html The Internet Underground
bush.cs.tamu.edu/~erich/alt.cp.faq.html alt.cyberpunk FAQ list
mailto:tk0jut2@mvs.cso.niu.edu Computer Underground Digest
www.wiretrip.net/rfp/2/index.asp Rain.Forest.Puppy

www.dbnet.ece.ntua.gr/~george/security/ The Hawk's security links
www.hideaway.net/security_links.html Hideaway.Net - Security Links
www.secure.cybercomm.nl/index2.html Secure Cybercommunications

dmoz.org/Computers/Hacking/Exploits
www.hack.co.za

Other:

www.scit.wlv.ac.uk/rfc/index.html                    RFCs in HTML format 
www.technotronic.com/tcpudp.html                Explanation of tcp, udp and a list of services
www.isi.edu/in-notes/iana/assignments/port-numbers   IANA Port number list
www-arc.com/sara   SARA - a satan like scanner
www.wwdsi.com/saint SAINT  - a satan like scanner
www.nessus.org NESSUS scanner
www.SecuriTeam.com Not very good.

tycho.usno.navy.mil The Official Source of Time for the Department of Defense and the Standard of Time for the United States

21.2 Security Organisations

21.2.1 FIRST (Forum of Incident Response and Security Teams)

FIRST is a coalition of international organisations (both government & private sector) which aims to foster co-operation in incident prevention, to prompt rapid reaction to incidents and to promote information sharing among members and the community at large. More details may be found on their WWW page www.first.org or by contacting them via email at mailto:first-sec@first.org . Normally users should contact their nearest first (see coming sections) and get on their mailing lists, rather than have FIRST having a mailing list for all security administrators in the world!

FIRST has over 30 members (as of Nov.1995). The most important members (in the author's opinion) are CERT, AUSCERT, DFN-CERT, CIAC. These groups are described in greater detail in the coming sections.

Most FIRST members use PGP to sign emails and MD5 to verify integrity of patch files, therefore it is advised to have these two utilities available.

21.2.1.1 CERT

CERT is the Computer Emergency Response Team that was formed by the US Defence Advanced Research Projects Agency (DARPA) in November 1988 in response to the needs exhibited during the Internet worm incident. The CERT charter is to work with the Internet community to facilitate its response to computer security events involving Internet hosts, to take proactive steps to raise the community's awareness of computer security issues, and to conduct research targeted at improving the security of existing systems.

Computer Emergency Response Team (CERT)
mailto:cert@cert.org (it is recommended that communications be encrypted with DES or PGP)
Tel. +1 412 268-7090

CERT advisories are interesting primarily for UNIX & VMS administrators, but also NT, with little for Windows/Mac operating systems (see CIAC below).
CERT completely revised their web presences in 1998, past CERT advisories are available in HTML format, alomg with much more from www.cert.org. To this extent this section is somewhat redundant now  (1999).

ftp://ftp.cert.org/pub/cert_advisories/ [An index is in 01-README file]
ftp://ftp.cert.org/pub/cert_summaries/
ftp://ftp.cert.org/pub/cert_bulletins/
ftp://ftp.cert.org/pub/tech_tips/packet_filtering
ftp://ftp.cert.org/pub/tech_tips/UNIX_configuration_guidelines
ftp://info.cert.org/pub/tools/
ftp://info.cert.org/pub/tech_tips/security_tools
ftp://info.cert.org/pub/incident_reporting_form
ftp://info.cert.org/pub/whois_how_to
ftp://info.cert.org/pub/FIRST/first-contacts

An Analysis Of Security Incidents On The Internet 1989-1995

Below is a complete list of advisories:

• The number of advisories in 1996 rose to 27 from 15-20 between 1991 and 1995. 1997 will probably be even more active.
• Sendmail is, and always was, a problem.
• Most UNIX vendors have problems, it is not confined to one or two.
• Many problems are due to buffer overruns and use of unclean environment variables.
• Automated attack tools to take advantage of known weaknesses are freely available on the Net. It no longer takes sophisticated hackers to launch an attack.

Vendor bulletins:

Cert Summaries:

21.2.1.2 European Emergency Response Teams

SIRCE (Europe-wide)

A pilot for a European-wide response team should start in 1997. The pilot project will last maximum 30 months, after which the permanent operation of SIRCE (Security Incident Response Co-ordination for Europe) will be put out to tender. The pilot is to be realised by UKERNA-DANTE. UKERNA is the UK national research networking organisation and DANTE is the non profit organisation of the research networks in Europe.

SWITCH-CERT (Switzerland)

The Swiss Academic and Research Network CERT in Switzerland provides a focal point for security information for Swiss system administrators. SWITCH-CERT post information to the members on all advisories from FIRST members as well as those from certain hacking groups. Swiss administrators are highly recommended to get on the SWITCH-CERT mailing list. Contact cert-staff@switch.ch.

DFN-CERT (Germany)

The German Federal Networks CERT co-ordinate security activities in Germany. Email dfncert@cert.dfn.de , tel. +49 040 5494-2262.

Italy: cert-it@dsi.unimi.it
Netherlands: cert-nl@surfnet.nl
England: cert@ja.ne t

21.2.1.3 AUSCERT

The Australian CERT, though geographically isolated, is sometimes the quickest when it comes to advising on new security problems and their solutions or workarounds.

See also http://www.auscert.org.au/information/advisories.html .
Email: auscert@auscert.org
Tel: +61 7 3365 4417

21.2.1.4 NASIRC (NASA Response Team)

The NASA team only offer support to NASA users, but do publish vulnerabilities found to FIRST members.

http://nasirc.nasa.gov
ftp://nasirc.nasa.gov
Tel. +1 800 762-7472

21.2.1.5 CIAC (U.S. department of energy (DOE) Response Team) (June'96)

CIAC (Computer Incident Advisory Capability) is the computer security response team for the U.S. department of energy (DOE) an the U.S. National Institute for Health (NIH). CIAC is a founding member of FIRST.

Tel. +1 510 422-8193
Email: ciac@llnl.gov

Previous CIAC notices, anti-virus software and other information are available at http://ciac.llnl.gov or ftp://ciac.llnl.gov . There are four self subscribing mailing lists (see below), however it is rarely necessary to subscribe directly to CIAC, since you nearest FIRST will forward you all CIAC advisories.

Email ciac-listproc@llnl.gov with one (or more) of the following lines in the email body:
subscribe CIAC-ANNOUNCE MYNAME, MYFORENAME MY_PHONE_NR
subscribe CIAC-NOTES MYNAME, MYFORENAME MY_PHONE_NR
subscribe SPI-ANNOUNCE MYNAME, MYFORENAME MY_PHONE_NR
subscribe SPI -NOTES MYNAME, MYFORENAME MY_PHONE_NR

CIAC supplies information in the following form:

1. Tools: diverse tools for DOS, UNIX & Macintosh are available for downloading.
2. Notes: Regular reports are produced detailing current security problems. Notes 1, 2, 94-03a, 94-04c, 94-05d, 95-06 to 95-12 and 96-01 were available in June 1996.
3. Bulletins: These document highlight specific problems. The current list of CIAC Bulletins (20.12.95) is divided up into groups A-G, A being 1989 and G 1995/96 (more or less):

21.2.2 French Organisations (TBD)

Clusis (TBD)

21.2.3 U.S. Organisations/agencies

NSA (National Security Agency)
The NSA developed the TCSEC and related Rainbow books. They are better known as powerful intelligence organisation, being part of the Department of Defense.

NIST (National Institute of Standards and Technology)
NIST distribute the Rainbow books and other security pamphlets. They work very closely with the NSA. (Are they a part of the NSA?)
TBD: Minimum Security Functional Requirement (MSFR)

NIST, Computer Security Labs,
Gaithersburg, Maryland 20899, USA
Tel. 301-975-2000

NCSC (National Computer Security Center)
As part of the NSA, the evaluate IT products according to the TCSEC standards. They are the original publishers of the Rainbow books.

NCSC
9800 Savage Road, Fort Meade, Maryland 20755,
Tel. 301-859-4371

NCSA (National Computer Security Association)
The (Government sponsored) NCSA is an independant organisation that offers many IT Security services, including education, conferences, news letters and follows Virus developments quite closely. They recently started certifying firewall and internet sites. NCSA also lobby security related issues in Washington. They are not affiliated to the NSA.
Annual membership for non-USA companies costs about $175.-.
Their "Infowar" conference is interesting.

NSCA 10 S. Courthouse Ave.,
Carlisle, Pennsylvania 17013, USA
Tel. 717-258-1816

COAST (Computer Operations, Audit and Security Technology)
At Purdue university, COAST is a focal point for security research.
http://www.coast.cs.purdue.edu .

21.3 Internet Hacking Groups

These groups produce detailed information on security holes found. In some cases, sample code for exploiting the holes are also published. It often takes CERT 6 months to publish advisories released by these groups, so get on their mailing list if security is a high priority for you.

8lgm (8 Little Green Men / 8 Legged Groove Machine)
To subscribe to this email list (recommended), send an email with body="subscribe 8lgm" to majordomo@8lgm.org . See also http://www.8lgm.org. The following is noted on the WWW site:

[8LGM] makes this information available in good faith, to make it possible for System Administrators to have the necessary tools to be able to fix their own systems. However [8LGM] does not endorse the usage of this information for any purposes.

List of Advisories (Feb 1997):

ASR (Avalon Security Research)
Recently (Nov.'95) a new group calling itself "Avalon Security Research" has started posting articles about security holes and how to exploit them on the Net. The ASR hacking group publish information of security holes they have uncovered. They describe themselves thus:

ASR is a loosely organized non-for -profit group. We have been working together on and off for around 4 years now. Recently we have decided to make our research public. This decision was based on a number of factors. Firstly we realize that computer security is now perhaps more than ever a paramount concert of the greater Internet community. This being the case we feel that it is important that all cards be on the table. To us this means strong advocacy of a full disclosure posture........and plan not only to release exploits but also Security Auditing tools of various natures...

To get on the mailing list, send an email to mcphee@cadvision.com.
The following is a list of bugs + exploitation scripts published on 12.2.96:

• Nov.'95: UNIX: Use of rpc.nfsd to chmod any directory on the system.
  => Fix/workaround: none available.
• Dec.'95: splitvt() bug. Root access may be gained easily by normal users.
  => Fix/workaround: See CIAC advisory G-08.
• 1996.1: rpc.nfsd bug found on Linux & SunOS. Root access may be gained easily.
  => Fix/workaround: It is not needed. Remove pr_start() function or fix the binary (a script is available from facq@u-bordeaux.fr ).

21.4 Security standards

This section is getting a little out of date and less useful, since most of this is now available online (it wasn't in 1996 when this was started). Have a look at www.itsec.gov.uk for the latest Acrobat copies of the relevant standards.

21.4.1 U.S. Standards: The Rainbow Books (local list)

The Rainbow books are a series of IT security documents famous by their cover colours. The most well known is the TCSEC or Orange Book (see next section). The following is a list of these books along with their colour, DoD reference numbers and title. This list strives to be complete, but could well be missing one or two books. The first three books on the list are the most interesting.

Orange Book DoD 5200.28-STD DoD TCSEC (Trusted Computer System Evaluation Criteria)
Green Book CSC-STD-002-85 Department of Defense Password Management Guideline
Yellow Book CSC-STD-003-85 Computer Security Requirements -- Guidance for Applying TCSEC in Specific Environments

Yellow Book CSC-STD-004-85 Technical Rationale Behind the above document.
Tan Book NCSC-TG-001 A Guide to Understanding Audit in Trusted Systems
Bright Blue Book NCSC-TG-002 Trusted Product Evaluation - A Guide for Vendors
Light Blue Book NCSC-TG-002-85 PC Security Considerations
Neon Orange Book NCSC-TG-003 Understanding Discretionary Access Control in Trusted Systems
Teal Green Book NCSC-TG-004 Glossary of Computer Security Terms
Red Book NCSC-TG-005 Trusted Network Interpretation of the TCSEC
Orange Book NCSC-TG-006 Understanding Configuration Management in Trusted Systems
Burgundy Book NCSC-TG-007 Understanding Design Documentation in Trusted Systems
Dark Lavender Book NCSC-TG-008 Understanding Trusted Distribution in Trusted Systems
Venice Blue Book NCSC-TG-009 Computer Security Subsystem Interpretation of the TCSEC
Aqua Book NCSC-TG-010 Understanding Security Modelling in Trusted Systems
Dark Red Book NCSC-TG-011 Trusted Network Interpretation Environments Guideline - Guidance for Applying the Trusted Network Interpretation
Pink Book NCSC-TG-013 Rating Maintenance Phase -- Program Document
Purple Book NCSC-TG-014 Guidelines for Formal Verification Systems
Brown Book NCSC-TG-015 Understanding Trusted Facility Management
Yellow-Green Book NCSC-TG-016 Guidelines for Writing Trusted Facility Manuals
Light Blue NCSC-TG-017 Understanding Identification and Authentication in Trusted Systems
Light Blue Book NCSC-TG-018 A Guide to Understanding Object Reuse in Trusted Systems
Blue Book NCSC-TG-019 Trusted Product Evaluation Questionnaire
Gray Book NCSC-TG-020A Trusted Unix Working Group (TRUSIX) Rationale for Selecting
Access Control List Features for the Unix System
Lavender Book NCSC-TG-021 Trusted Data Base Management System Interpretation of TCSEC
Yellow Book NCSC-TG-022 A Guide to Understanding Trusted Recovery in Trusted Systems
Bright Orange Book NCSC-TG-023 Understanding Security Testing and Test Documentation in Trusted Systems
Purple Book NCSC-TG-024 (Volume 1/4) A Guide to Procurement of Trusted Systems: An Introduction to Procurement Initiators on Computer Security Requirements
Purple Book NCSC-TG-024 (Volume 2/4) A Guide to Procurement of Trusted Systems: Language for RFP Specifications and Statements of Work - An Aid to Procurement initiators.
Purple Book NCSC-TG-024 (Volume 3/4) A Guide to Procurement of Trusted Systems: Computer Security Contract Data Requirements List and Data Item Description Tutorial
Purple Book NCSC-TG-024 (Volume 4/4) A Guide to Procurement of Trusted Systems: How to Evaluate a Bidder's Proposal Document - An Aid to Procurement Initiators and Contractors
Green Book NCSC-TG-025 Understanding Data Remanence in Automated Information Systems
Hot Peach Book NCSC-TG-026 Writing the Security Features User's Guide for Trusted Systems
Turquoise Book NCSC-TG-027 A Guide to Understanding Information System Security Officer Responsibilities for Automated Information Systems
Violet Book NCSC-TG-028 Assessing Controlled Access Protection
Blue Book NCSC-TG-029 Introduction to Certification and Accreditation
Light Pink Book NCSC-TG-030 A Guide to Understanding Covert Channel Analysis of Trusted Systems

21.4.2 The TCSEC "Orange Book" (local copy, or see UK ITSEC)

21.4.2.1 Introduction

In 1983, the American Department of Defense (DoD) (in fact the National Computer Security Centre[1]), release the first version of the TCSEC or Orange Book (named after it's orange cover). It was further updated in 1985 and published as a Standard (DOD5200.28-STD). The Orange Book defines guidelines for evaluating the security of computer systems. Many other related standards were written, known as the "Rainbow Series".

• Systems are divided into four hierarchical groups A, B (B1, B2, B3), C (C1, C2), D. Class A systems are the most secure and class D systems are those who failed to meet the criteria of any of the other classes.
• The requirements for each class are divided into the following categories: Security Policy, Marking, Identification, Accountability, Assurance and Continuous Protection.
• The principal difference between C and B class systems is in the area of access control. In C2, object owners decide who can access their object, to what degree (this is known as DAC - Discretionary Access Control). In B, objects have a security classification independent of the owner - so if a user receives a copy of an object marked "secret", the user can not change the classification of this object, or give it to others who are not cleared to access "secret" objects (this is known as MAC - Mandatory Access Control). B class systems need "data labelling" to implement MAC.
• If the NSA evaluates a System and grants it a (say) C2 rating, it is then listed on the Evaluated Products List (EPL). The system is evaluated to a certain level under certain conditions, which may not actually reflect the normal everyday usage of a system.
• C2 class commercial systems are not uncommon, B class systems are rare and are mainly used in the Military field.
• A key notion in the TCSEC is the idea of a TCB (Trusted Computing Base). A TCB must provide: protection from interference with the TCB, address space separation, trusted path, least-privilege principle, continuity of operations.
• A summary of commercial operating systems evaluated according to TCSEC is to be found in the "Operating Systems Overview" chapter.
  

21.4.2.2 Contacts

Infosec Awareness Office [to order documents]
+1 (410) 766-8729

Government Printing Office [to order the Infosec Systems & Security Catalogue]
+1 (202) 512-1800

Evaluations Office
+1 (410) 859-4458

The following is a direct extract from the Orange Book for classes C1 and C2:

21.4.2.3 2.0 DIVISION C: DISCRETIONARY PROTECTION

Classes in this division provide for discretionary (need-to-know) protection and, through the inclusion of audit capabilities, for accountability of subjects and the actions they initiate.

CLASS (C1): DISCRETIONARY SECURITY PROTECTION
The Trusted Computing Base (TCB) of a class (C1) system nominally satisfies the discretionary security requirements by providing separation of users and data. It incorporates some form of credible controls capable of enforcing access limitations on an individual basis, i.e., ostensibly suitable for allowing users to be able to protect project or private information and to keep other users from accidentally reading or destroying their data. The class (C1) environment is expected to be one of co-operating users processing data at the same level(s) of sensitivity. The following are minimal requirements for systems assigned a class (C1) rating:

2.1.1 Security Policy
2.1.1.1 Discretionary Access Control: The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control of those objects by named individuals or defined groups or both.
2.1.2 Accountability
2.1.2.1 Identification and Authentication: The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall use a protected mechanism (e.g., passwords) to authenticate the user's identity. The TCB shall protect authentication data so that it cannot be accessed by any unauthorised user.
2.1.3 Assurance
2.1.3.1 Operational Assurance
2.1.3.1.1 System Architecture: The TCB shall maintain a domain for its own protects it from external interference or tampering (e.g., by modification of its code or data structures Resources controlled by the TCB may be a defined subset of the subjects and objects in the ADP system.
2.1.3.1.2 System Integrity: Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB.
2.1.3.2 Life-Cycle Assurance
2.1.3.2.1Security Testing: The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. Testing shall be done to assure that there are no obvious ways for an unauthorised user to bypass or otherwise defeat the security protection mechanisms of the TCB.(See the Security Testing Guidelines.)
2.1.4 Documentation
2.1.4.1 Security Features User's Guide: A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another.
2.1.4.2 Trusted Facility Manual: A manual addressed to the ADP System Administrator shall present cautions about functions and privileges that should be controlled when running a secure facility.
2.1.4.3 Test Documentation: The system developer shall provide to the evaluators a document that describes the test plan, test procedures that show how the security mechanisms were tested, and results of the security mechanisms' functional testing.
2.1.4.4 Design Documentation: Documentation shall be available that provides a description the manufacturer's philosophy of protection and an explanation of how this philosophy is translated into the TCB. If the TCB is composed of distinct modules, the interfaces between these modules shall be described.

CLASS (C2):CONTROLLED ACCESS PROTECTION
Systems in this class enforce a more finely grained discretionary access control than (C1) systems, making users individually accountable for their actions through login procedures, auditing of security-relevant events, and resource isolation. The following are minimal requirements for systems assigned a class (C2) rating:

2.2.1 Security Policy
2.2.1.1 Discretionary Access Control: The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals, or defined groups of individuals, or by both, and shall provide controls to limit propagation of access rights. The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorised access. These access controls shall be capable of including or excluding access to the granularity of a single user. Access permission to an object by users not already possessing access permission shall only be assigned by authorised users.
2.2.1.2 Object Reuse: All authorisations to the information contained within a storage object shall be revoked prior to initial assignment, allocation or reallocation to a subject from the TCB's pool of unused storage objects. No information, including encrypted representations of information, produced by a prior subject's actions is to be available to any subject that obtains access to an object that has been released back to the system.
2.2.2 Accountability
2.2.2.1 Identification and Authentication: The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall use a protected mechanism (e.g., passwords) to authenticate the user's identity. The TCB shall protect authentication data so that it cannot be accessed by any unauthorised user. The TCB shall be able enforce individual accountability by providing the capability to uniquely identify each individual ADP system user. The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual.
2.2.2.2 Audit: The TCB shall be able to create, maintain, and protect from modification or unauthorised access or destruction an audit trail of accesses to the objects it protects. The audit data shall be protected by the TCB so that read access to it is limited to those who are authorised for audit data. The TCB shall be able to record the following types of events:use of identification and authentication mechanisms, introduction or objects into a user's address space (e.g., file open, initiation), deletion of objects, and actions taken by computer operators and system administrators and/or system security officers, and other security relevant events. For each recorded event, the audit record shall identify:datetime of the event, user, type of event, and success or failure of the event. For identification/authentication events the origin of request (e.g., terminal ID) shall be included in the audit record. For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object. The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity.
2.2.3 Assurance
2.2.3.1 Operational Assurance
2.2.3.1.1System Architecture: The TCB shall maintain a domain for its own that protects it from external interference or tampering(e.g., by modification of its code or data structures Resources controlled by the TCB may be a defined subset of the subjects and objects in the ADP system. The TCB shall isolate the resources to be protected so that they are subject to the access control and auditing requirements.
2.2.3.1.2System Integrity: Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB.
2.2.3.2 Life-Cycle Assurance
2.2.3.2.1Security Testing: The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. Testing shall be done to assure that there are no obvious ways for an unauthorised user to bypass or otherwise defeat the security protection mechanisms of the TCB. Testing shall also include a search for obvious flaws that would allow violation of resource isolation, or that would permit unauthorised access to the audit or authentication data.(See the Security Testing guidelines.)
2.2.4 Documentation
2.2.4.1 Security Features User's Guide: A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another.
2.2.4.2 Trusted Facility Manual: A manual addressed to the ADP system administrator shall present cautions about functions and privileges that should be controlled when running a secure facility. The procedures for examining and maintaining the audit files as well as the detailed audit record structure for each type of audit event shall be given.
2.2.4.3 Test Documentation: The system developer shall provide to the evaluators a document that describes the test plan, test procedures that show how the security mechanisms were tested, and results of the security mechanisms' functional testing.
2.2.4.4 Design Documentation: Documentation shall be available that provides a description the manufacturer's philosophy of protection and an explanation of how this philosophy is translated into the TCB. If the TCB is composed of distinct modules, the interfaces between these modules shall be described.

21.4.3 The ITSEC - "European Orange Book"(local copy, or see UK ITSEC)

21.4.3.1 Overview

ITSEC (Information Technology Security Evaluation Criteria) is a set of harmonised Criteria from France, Germany, the Netherlands & the United Kingdom. It was adopted by the EU (European Community) as a standard for all member states in April 1995. A summary of commercial operating systems evaluated according to ITSEC is to be found in the "Operating Systems Overview" chapter. The ITSEM [itsem] is a guide to using the ITSEC - it is described in the following section.

When a product or system (hereafter called a TOE: target of Evaluation) is evaluated according to ITSEC:

• A security specification (called a Security Target) is defined by the Sponsor. This defines the Security objectives (the contribution to security that the TOE is intended to achieve), threats, Security Enforcing Functions, and security mechanisms. The Security Target may also be one of the example functionality classes.
• The TOE is evaluated against the Security Target. Assurance is the level confidence in the security provided by the TOE. It is defined as effectiveness (the TOE can resist attacks or accidents and it is unlikely that the TOE could be insecurely configured with the administrator/user knowing) and correctness (have the security enforcing functions been implemented?).
  • Effectiveness criteria: Construction (Suitability/Binding of functionality, Strength of mechanisms, construction vulnerability assessment) and Operation (ease of use, operational vulnerability assessment).
  • Correctness criteria: Construction (development process/environment) and operation (operational documentation/environment).
• The result is a "Certification Report" and an "Evaluation Technical Report".
  ITSEC separates security functionality and assurance. There are assurance levels E1 through E6. The higher the assurance level, the surer one can be that the stated security functionality works correctly and as described and that it is resistant to attack.

ITSEC defines example functionality classes F-C1, C2, B1, B2, B3 which correspond to the TCSEC classes and the new classes IN, AV, DI, DC and DX which are interesting because they include networking (which is missing from TCSEC. These classes describe a set of standard security functions. The ITSEC and TCSEC correspond as follows:

ITSEC TCSEC
E1, F-C1 == C1
E2, F-C2 == C2
E3, F-B1 == B1
E4, F-B2 == B2
E5, F-B3 == B3
E6, F-B3 == A1

ITSEC defines the following functionality classes in addition to ITSEC:

IN This class is for systems with high integrity requirements for data & programs.
AV This class is for systems with high availability functions.
DI This class is for systems with high integrity requirements for data transmission.
DC This class is for systems with high confidentiality requirements for data transmission.
DX This class is for systems with high integrity & confidentilaity requirements for data
transmission.

ITSEC suggest that requirements be analysed under the headings: Accountability, Identification & Authentication, Audit, Object Reuse, Access Control, Accuracy, Data Exchange and Reliability of Service. Mechanism or countermeasure strength is defined as being basic, medium or high.

Only class F-DX is presented here for brevity, as it contains interesting new review criteria not found in TCSEC.

21.4.3.2 Extract from the ITSEC Introduction

Following extensive international review version 1.2 of the ITSEC is issued, with the approval of the (informal) EC advisory group, SOG-IS (Senior Officials Group - Information Systems Security), for operational use within evaluation and certification schemes, for a provisional period of two years from the date of issue. The practical experience acquired will be used to review and further develop the ITSEC at the end of this period. In addition, considerations arising from further international harmonisation will also be taken into account.

0.1 In the course of only four decades, Information Technology (IT) has come to play an important, and often vital, role in almost all sectors of organised societies. As a consequence, security has become an essential aspect of Information Technology.

0.2 In this context, IT security means,
- confidentiality - prevention of the unauthorised disclosure of information;
- integrity - prevention of the unauthorised modification of information;
- availability - prevention of the unauthorised withholding of information or resources.
0.3 An IT system or product will have its own requirements for maintenance of confidentiality, integrity and availability. In order to meet these requirements it will implement a number of technical security measures, in this document referred to as security enforcing functions, covering, for example, areas such as access control, auditing, and error recovery. Appropriate confidence in these functions will be needed: in this document this is referred to as assurance, whether it is confidence in the correctness of the security enforcing functions (both from the development and the operational points of view) or confidence in the effectiveness of those functions.
0.4 Users of systems need confidence in the security of the system they are using. They also need a yardstick to compare the security capabilities of IT products they are thinking of purchasing. Although users could rely upon the word of the manufacturers or vendors of the systems and products in question, or they could test them themselves, it is likely that many users will prefer to rely on the results of some form of impartial assessment by an independent body. Such an evaluation of a system or product requires objective and well-defined security evaluation criteria and the existence of a certification body that can confirm that the evaluation has been properly conducted. System security targets will be specific to the particular needs of the users of the system in question, whereas product security targets will be more general so that products that meet them can be incorporated into many systems with similar but not necessarily identical security requirements.
0.5 For a system, an evaluation of its security capabilities can be viewed as a part of a more formal procedure for accepting an IT system for use within a particular environment. Accreditation is the term often used to describe this procedure. It requires a number of factors to be considered before a system can be viewed as fit for its intended purpose: it requires assurance in the security provided by the system, a confirmation of management responsibilities for security, compliance with relevant technical and legal/regulatory requirements, and confidence in the adequacy of other non-technical security measures provided in the system environment. The criteria contained in this document are primarily concerned with technical security measures, but they do address some non-technical aspects, such as secure operating procedures for personnel, physical and procedural security (but only where these impinge on the technical security measures).
0.6 Much work has been done previously on the development of IT security evaluation criteria, although for slightly different objectives according to the specific requirements of the countries or bodies involved. Most important of these, and a precursor to other developments in many respects, was the Trusted Computer System Evaluation Criteria [TCSEC], commonly known as the TCSEC or "Orange Book", published and used for product evaluation by the US Department of Defense. Other countries, mostly European, also have significant experience in IT security evaluation and have developed their own IT security criteria. In the UK this includes CESG Memorandum Number 3 [CESG3], developed for government use, and proposals of the Department of Trade and Industry, the "Green Book" [DTIEC], for commercial IT security products. In Germany, the German Information Security Agency published a first version of its own criteria in 1989 [ZSIEC], and at the same time criteria were being developed in France, the so-called "Blue-White-Red Book" [SCSSI].
0.7 Seeing that work was going on in this area, and much still needed to be done, France, Germany, the Netherlands and the United Kingdom recognised that this work needed to be approached in a concerted way, and that common, harmonised IT security criteria should be put forward. There were
three reasons for harmonisation:
a) much experience had been accumulated in the various countries, and there would be much to gain by jointly building on that experience;
b) industry did not want different security criteria in the different countries;
c) the basic concepts and approaches were the same, across countries and even across commercial, government and defence applications.
0.8 It was therefore decided to build on the various national initiatives, taking the best features of what had already been done and putting them in a consistent, structured perspective. Maximum applicability and compatibility with existing work, most notably the US TCSEC, was a constant consideration in this process. Though it was initially felt that the work would be limited to harmonisation of existing criteria, it has sometimes been necessary to extend what already existed.

21.4.3.3 Contacts

EU Commission of the European Communities
Directorate XII/F SOG-IS Secretariat
Rue De la Loi 200
B-1049 Brussels, Belgium

Germany Bundesamt für Sicherheit in der Informatik
Am Nippenkreuz 19, D-5300 Bonn
+49-228-9582.111 General Number
+49-228-9582.129 Certification information
+49-228-9582.141 Documentation

Netherlands Netherlands National Comsec Agency
Bezuidenhoutseweg 67
P.O. Box 200061, NL-2500 EB The Hague

France Service Central de la Sécurité des Systèmes d'Information
Division Information et Systèmes
18 Rue du Docteur Zamenhof, F-92131 Issy les Moulineaux

UK Head of the Certification Body
UK IT Security Evaluation and Certification Scheme
P.O. Box 152, Cheltenham, GB-GL52 5UF
+41-1242-238739 ext. 5103
cbsec@itsec.gov.uk
http://www.itsec.gov.uk

21.4.3.4 Example functionality class F-DX

Objectives
A.100 Example functionality class F-DX is intended for networks with high demands on the confidentiality and integrity of the information to be exchanged. For example, this can be the case when sensitive information has to be exchanged via insecure (for example: public) networks.

Identification and Authentication
A.101 The TOE shall uniquely identify and authenticate users. This identification and authentication shall take place prior to all other interactions between the TOE and the user. Other interactions shall only be possible after successful identification and authentication. The authentication information shall be stored in such a way that it can only be accessed for review or modification by authorised users. For every interaction the TOE shall be able to establish the identity of the user.

A.102 Prior to the exchange of user data the peer entity (computer, process or user) shall be uniquely identified and authenticated. User data shall only be exchanged after identification and authentication have been successfully completed. On receipt of data it shall be possible to uniquely identify and authenticate the sender of the data. All authentication information shall be protected against unauthorised access and forgery.

Accountability
A.103 The TOE shall contain an accountability component which is able, for each of the following events, to log that event together with the required data:
a) Use of the identification and authentication mechanism:
Required data: Date; time; initiator of the identification and authentication; name of the subject to be identified; success or failure of the action.
b) Identified errors in the data exchange:
Required data: Date; time; peers in the data exchange; type of the error; success or failure of the attempted correction.
c) Connection establishment:
Required data: Date; time; user identity of the initiator; name of the peer entity (computer, process or user); establishment parameters (if these vary).
d) Special data exchange transactions:
Required data: Date; time; user identity of the transmitter; user identity of the recipient; user information communicated; date and time of the receipt of the data.
A.104 Unauthorised users shall not be permitted to access accountability data. It shall be possible to selectively account for the actions of one or more users. Tools to examine and to maintain the accountability files shall exist and be documented. These tools shall allow the actions of one or more users to be identified selectively. The structure of the accountability records shall be described completely.

Audit
A.105 Tools to examine the accountability files for the purpose of audit shall exist and be documented. These tools shall allow the actions of one or more users to be
identified selectively.

Data Exchange

Access Control
A.106 All information previously transmitted which can be used for unauthorised decryption shall be protected in such a way that only such persons who positively need such access in order to be able to perform their duties can access this data.

Data Confidentiality
A.107 The TOE shall offer the possibility of end-to-end encryption which ensures confidentiality regarding the recipient over large sections of the communication channel. In addition, traffic flow confidentiality shall also be guaranteed on designated data communication links.

Data Integrity
A.108 The TOE shall be designed in such a way that unauthorised manipulation of user data and accountability data and unauthorised replay of data are reliably identified as errors.

21.4.4 ITSEM (extracts) (local copy, or see UK ITSEC)

..........

Chapter 0.1 Introduction
0.1.5 The IT Security Evaluation Manual (ITSEM) builds on the ITSEC Version 1.2, describing how a Target Of Evaluation (TOE) should be evaluated according to these criteria. The specific objective of the ITSEM is to ensure that there exists a harmonised set of evaluation methods which complements the ITSEC.

0.1.6 The ITSEM is a technical document, aimed predominantly at partners in evaluation (primarily evaluators but also sponsors and certifiers), but it is also of interest to vendors, developers, system accreditors and users. It contains sufficient detail of evaluation methods and procedures to enable technical equivalence of evaluations performed in different environments to be demonstrated. The document will be freely available. The ITSEM will apply to evaluations carried out both in commercial and government sectors.
..........
Chapter 0.1 Introduction
Assets, Threats, Risks, Confidence and Countermeasures
0.1.1 Information Technology (IT) has become essential to the effective conduct of business and the affairs of state, and is becoming increasingly important to the affairs of private individuals affected by the use of IT. Information is something to be gained and protected in order to advance one's business or private affairs, and should therefore be regarded as an asset. The importance of such assets is usually expressed in terms of the consequential damage resulting from the manifestation of threats. Damage may be caused directly or indirectly, by disclosure, improper modification, destruction or abuse of information. Risk increases with the size of the likely damage and the likelihood of the threats being manifested.
0.1.2 The information in IT systems has to be protected against threats which lead to harmful impacts on assets. Threats can be deliberate (e.g. attacks) or inadvertent (e.g. mistakes or failures).
0.1.3 In order to reduce risk, specific countermeasures will be selected. These countermeasures will be physical, personnel, procedural or technical in nature. Technical countermeasures or IT countermeasures are the security enforcing functions and mechanisms of the IT system; non-technical countermeasures or non-IT countermeasures are the physical, personnel and procedural countermeasures. ITSEC evaluation is principally concerned with technical countermeasures.
0.1.4 The primary security objective of an IT system is to reduce the associated risks to a level acceptable to the organisation concerned. This can be achieved by security functions and features of the IT system.
0.1.5 The confidence that may be held in the security provided by the IT system is referred to as assurance. The greater the assurance, the greater the confidence that the system will protect its assets against the threat with an acceptable level of residual risk.
0.1.6 The higher the ITSEC evaluation level and strength of mechanisms, the greater the assurance the user can have in the countermeasures built into the IT system or product. The evaluation level required by a user depends on the acceptable level of known residual risk and can only be determined by means of a threat and risk analysis for a specific case. Security and costs have to be balanced. Products or systems with higher evaluation levels will usually be more expensive, as the costs for development and evaluation are likely to increase with increasing evaluation level. Guidance on how to determine an evaluation level as a function of environmental parameters is given in, for example, [GISA2]. Specific advice can be sought from the national organisations mentioned in part 2 of the ITSEM.

..........
Security Evaluation
6.4.11 It is impossible to produce practical IT systems which are absolutely secure. This is because of the complexity of IT systems, and the variety of threats which they have to counter.
6.4.12 It is possible, however, to provide some confidence in the security of a computer system. The favoured approach is for an independent body (called an IT Security Evaluation Facility, or ITSEF) to examine the system design and documentation in detail to search for security vulnerabilities. This examination is called a security evaluation. A system passes its evaluation if it is found to be free from exploitable security vulnerabilities; otherwise it fails.
6.4.13 If a system has passed a security evaluation, it is likely that it will provide some degree of security but it cannot be considered absolutely secure, for the following reasons:
a) vulnerabilities may exist which have not been discovered by the evaluators, due to the level of information available to the evaluators;
b) the system may be used, operated, managed or configured insecurely;
c) some of the threats in the environment may not have been included in the security target.
6.4.14 Therefore, an evaluated system should be seen as having a role in maintaining an organisation's security, but it does not take on all responsibility for security. Users of all types still have a part to play.
..........

21.4.5 TTAP

The following is an extract from the FIST WWW page:

The TTAP (Trust Technology Assessment Program) is a joint National Security Agency (NSA) and National Institute for Standards and Technology (NIST) effort to commercialise the level of trust evaluation for commercial-off-the-shelf (COTS) products. Under the auspices of the National Voluntary Laboratory Accreditation Program (NVLAP), TTAP will establish, approve , and oversee commercial evaluation facilities focusing initially on products with features and assurances characterised by the TCSEC B1 and lower levels of trust. Vendors desiring a level of trust evaluation will contract with an accredited laboratory and pay a fee for their evaluation.

The first TTAP workshop will be in spring 1996. It will be interesting to see what TTAP does for allowing users to choose Operating Systems based on their "security rating".

21.4.6 Common Criteria 1.0 (old V1 local copy, or see newer V2 at UK ITSEC)

The following description is from NIST ( http://csrl.ncsl.nist.gov/nistpubs/cc ):

In 1985 the US produced a set of security evaluation criteria called the TCSEC (Trusted Computer Security Evaluation Criteria or Orange book). These criteria provided a couple of levels (C1, C2, B1, B2, B3, A1) which required specific security functionality, suitable for a specific set of defined environments. After this TCSEC, the Europeans developed the ITSEC (IT Security Evaluation Criteria), Canada the CTCPEC, and finally the US the Federal Criteria. Since these criteria are not compatible with each other, it was decided to try to harmonize all these criteria into a new set of security evaluation criteria called the Common Criteria (or simply the CC).

The Common Criteria main objective is to provide a set of security evaluation criteria that can be used for all IT security products. At the same time it provides a nice concise set of possible security requirements that could be desired in a product.
The Common Criteria are not finalized yet. At this moment the Common Criteria for Information Technology Security (CC) version 1.0, January 31, 1996, is now available for public review and comment. Common Criteria. Based on reviews and trial evaluations the CC can still be hanged. The intention is that ISO will accept the Common Criteria as international standard, and has already been provided to ISO.
The ISO/IEC/JTC1/SC27/WG3 "Evaluation Criteria for IT Security" have the aim of define a worldwide standard criteria by 1998.

Footnotes:
[1] Apparently the NCSC have now a Web presence, but not the NSA division which evaluates systems.

                 Previous     Next      Top   Detailed TOC      Last Update: 08 mai 2002