previous  next  Title  Contents  Index   Previous   Next   Top   Detailed TOC         Last Update: 08 mai 2002

21 Appendix C: Reference Material

NOTE: I keep a list of more recent references/links, updated on a weekly basis at 


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. <>
Tik-110.501 Seminar on Network Security
Practical Cryptosystems and their Strength
Janne Frösen Department of Computer Science
Helsinki University of Technology     2.11.1995
Security evaluation standards
  • TCSEC / Orange Book
  • Common criteria (old version)


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:
Cryptography and Liberty 1999 - An International Survey of Encryption Policy
This is the best overview of international cryto policies I know of.  
  • UNIX Programming tips, SunWorld.
  • Code Signing: how-to


System Administration
  • Internet Webservers: best practices


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!

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

Virus Contacts (oldish):

Newsgroup: comp.virus PC Viruses
PC Virus Info.
body= "SUB VIRUS-L myname@my.domain"
Macro virus list

Response Team Contacts:

FIRST [FIRST home page]

SWITCH CERT Switzerland
CERT *recommended*
CERT tools
Other European Teams: see next section.
Australian CERT [The Aussies are very up-to-date.]

CIAC 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
Best of Security (bos)
Security mailing lists (local copy)
SANS Network Security Digest
     body='subscribe Network Security Digest your name'

Newsgroups General security news://
                    Evils of technology news://comp.risks
                    Security Announcements news:// [lots of goodies in CH] [Spafford's index of links: v.good] [index to lots of network/Unix pages] [WWW server security] [broken] [WWW cgi scripts security] [ as above]
IIS Security Configuration

Vendor Contacts/patch sources:

Unix security [not verified]

Sun "Customer Warning System" Security alert , subject="subscribe CWS", Tel. +1 415 688-9081
Sun sysadmin
           body="add myname@ my.domain"
Security bulletins
Sun & java security    
Newsgroup Solaris news://comp.unix.solaris
   Switzerland   Contract patches    
   Patch download tool WGET
   PatchDiag tool

Precompiled freeware for Sun
Solaris Guide index:
Sunworld sunwhere index of resources
Jean Chouanard's Package for hardening Solaris
Jens Vöckler's script for tuning the Solaris TCP/IP stack (excellent for performance, security and learning ndd) .

Hewlett Packard
HP Security list body="subscribe security_info"
HP-UX sysadmin body="subscribe hpux-admin"
Newsgroup HP-UX news://comp.sys.hp.hpux

DEC: , Tel. +1 719 592-4689
OSF/1 sysadmin body="subscribe alpha-osf-managers"

BSDI sysadmin
Santa Cruz Operation
Linux: Linux Emergency Response Team:

Stampede GNU/Linux
Yellow Dog Linux and Black Lab Linux
Kondara MNU/Linux


Email , Tel. +1 800 800-4SGI
Patches: Security advisories and patches from SGI can be obtained via ftp from or it's mirror in the directory Security or Patches.

For issues relating to the above patches, refer to . For new issues, email

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

IBM/AIX: , Tel. +1 800 237-5511 [Some AIX security patches] [Security Products & services]


Microsoft/Windows NT:
NT Security Issues
NTBugtraq body= "SUB NTBUGTRAQ Your Name"
NT Security from ISS body="subscribe ntsecurity"
NT, Explorer security              *recommended*
Microsoft Security [NT security] [NT frequently asked questions]

Article which explains different router password storage mechanisms & weakensses

For more lists of vendors, see


Firewalls "subscribe firewalls"
A digest is also available.

Security Hacking (full disclosure) groups:

Bug track discussion list

Bugtraq database

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

Currently inactive groups:

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.    The home for nmap, among other things      An interesting scanner  Collection of tools  NT password cracking & NFR plug-ins The alt.2600/#hack FAQ Intro. Unix / net / hack page Phrack Phrack Unix /net /hack page US mirror Cold Fire's Web Page  2600 Magazine The Internet Underground alt.cyberpunk FAQ list Computer Underground Digest Rain.Forest.Puppy The Hawk's security links Hideaway.Net - Security Links Secure Cybercommunications

Other:                    RFCs in HTML format                Explanation of tcp, udp and a list of services   IANA Port number list   SARA - a satan like scanner SAINT  - a satan like scanner NESSUS scanner Not very good. 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 or by contacting them via email at . 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. 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) (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 To this extent this section is somewhat redundant now  (1999). [An index is in 01-README file]

An Analysis Of Security Incidents On The Internet 1989-1995

Below is a complete list of advisories:

CA-88:01.ftpd.hole CA-94:05.MD5.checksums
CA-89:01.passwd.hole CA-94:06.utmp.vulnerability
CA-89:03.telnet.breakin.warning CA-94:08.ftpd.vulnerabilities
CA-89:04.decnet.wank.worm CA-94:09.bin.login.vulnerability
CA-89:05.ultrix3.0.hole CA-94:10.IBM.AIX.bsh.vulnerability
CA-89:06.ultrix3.0.update CA-94:11.majordomo.vulnerabilities
CA-89:07.sun.rcp.vulnerability CA-94:12.sendmail.vulnerabilities
CA-90:01.sun.sendmail.vulnerability CA-94:13.SGI.IRIX.Help.Vulnerability
CA-90:03.unisys.warning CA-94:15.NFS.Vulnerabilities
CA-90:04.apollosuid.vulnerability CA-95:01.IP.spoofing
CA-90:05.sunselection.vulnerability CA-95:01.IP.spoofing.attacks.and.hijacked.terminal.connections
CA-90:06a.NeXT.vulnerability CA-95:02.binmail.vulnerabilities
CA-90:07.VMS.ANALYZE.vulnerabiliy CA-95:03.telnet.encryption.vulnerability
CA-90:08.irix.mail CA-95:03a.telnet.encryption.vulnerability
CA-90:09.vms.breakins.warning CA-95:04.NCSA.http.daemon.for.unix.vulnerability
CA-90:10.attack.rumour.warning CA-95:05.sendmail.vulnerabilities
CA-90:11.Security.Probes CA-95:06.satan
CA-91:01a.SunOS.mail.vulnerability CA-95:07a.REVISED.satan.vul
CA-91:02a.SunOS.telnetd.vulnerability CA-95:08.sendmail.v.5.vulnerability
CA-91:03.unauthorized.password.change.request CA-95:09.Solaris-ps.vul
CA-91:05.Ultrix.chroot.vulnerability CA-95:10.ghostscript
CA-91:06.NeXTstep.vulnerability CA-95:11.sun.sendmail-oR.vul
CA-91:07.SunOS.source.tape.vulnerability CA-95:12.sun.loadmodule.vul
CA-91:08.systemV.login.vulnerability CA-95:13.syslog.vul
CA-91:09.SunOS.rpc.mountd.vulnerability CA-95:14.Telnetd_Environment_Vulnerability
CA-91:10a.SunOS.lpd.vulnerability CA-95:15.SGI.lp.vul
CA-91:11.Ultrix.LAT-Telnet.gateway.vulnerability CA-95:16.wu-ftp_vulnerability
CA-91:12.Trusted.Hosts.Configuration.vulnerability CA-95:17.rpc.ypupdated
CA-91:13.Ultrix.mail.vulnerability CA-95:18-Widespread attacks
CA-91:14.IRIX.mail.vulnerability CA-96.01.UDP_service_denial
CA-91:15.NCSA.Telnet.vulnerability CA-96.02 BIND Version 4.9.3
CA-91:16.SunOS.SPARC.Integer_Division.vulnerability CA-96.03 Vulnerability in Kerberos 4 & 5
CA-91:17.DECnet-Internet.Gateway.vulnerability CA-96.04 Corrupt information from Network Servers
CA-91:18.Active.Internet.tftp.Attacks CA-96.05.java_applet_security_mgr
CA-91:19.AIX.TFTP.Daemon.vulnerability CA-96.06.cgi_example_code
CA-91:20.rdist.vulnerability CA-96.07.java_bytecode_verifier
CA-92:01.NeXTstep.configuration.vulnerability CA-96.08.pcnfsd
CA-92:02.Michelangelo.PC.virus.warning CA-96.09.rpc.statd
CA-92:03.Internet.Intruder.Activity CA-96.10.nis+_configuration
CA-92:04.ATT.rexecd.vulnerability CA-96.11.interpreters_in_cgi_bin_dir
CA-92:05.AIX.REXD.Daemon.vulnerability CA-96.12.suidperl_vul
CA-92:06.AIX.uucp.vulnerability CA-96.13.dip_vul
CA-92:07.AIX.passwd.vulnerability CA-96.14.rdist_vul
CA-92:08.SGI.lp.vulnerability CA-96.15.Solaris_KCMS_vul
CA-92:09.AIX.anonymous.ftp.vulnerability CA-96.16.Solaris_admintool_vul
CA-92:10.AIX.crontab.vulnerability CA-96.17.Solaris_vold_vul
CA-92:11:SunOS.Environment.vulnerability CA-96.18.fm_fls
CA-92:12.REVISED.SunOS.rpc.mountd.vulnerability CA-96.19.expreserve
CA-92:13.SunOS.NIS.vulnerability CA-96.20.sendmail_vul
CA-92:14.Altered.System.Binaries.Incident CA-96.21.tcp_syn_flooding
CA-92:15.Multiple.SunOS.vulnerabilities.patched CA-96.22.bash_vuls
CA-92:16.VMS.Monitor.vulnerability CA-96.23.workman_vul
CA-92:17.HP.NIS.ypbind.vulnerability CA-96.24.sendmail.daemon.mode
CA-92:18.VMS.Monitor.vulnerability.update CA-96.25.sendmail_groups
CA-92:20.Cisco.Access.List.vulnerability CA-96.27.hp_sw_install
CA-92:21.ConvexOS.vulnerabilities CA-97.01.flex_lm
CA-93:01.REVISED.HP.NIS.ypbind.vulnerability CA-97.02.hp_newgrp
CA-93:02a.NeXT.NetInfo._writers.vulnerabilities CA-97.03.csetup
CA-93:03.SunOS.Permissions.vulnerability CA-97.04.talkd
CA-93:04a.Amiga.finger.vulnerability CA-97.05.sendmail
CA-93:05.OpenVMS.AXP.vulnerability CA-97.06.rlogin-term

Vendor bulletins:

VB-94:01.sco VB-95:10 - Vulnerability in elm V2.4 PL 24 PPP
VB-94:02.dec VB-96.01.splitvt bsd RZ
VB-95:01.hp VB-96.02.sgi Packages VB-96.13 HP, elm
VB-95:02.sgi VB-96.03.sun catalyst CDware VB-96.14 SGI, IRIX tools
VB-95:03.hp VB-96.04.bsdi Kernel VB-96.15 SCO
VB-95:04.venema VB-96.05.dec VB-96.16 Transarc, AFS/DFS
VB-95:05.osf VB-96.06.freebsd VB-96.17 Linux VB-96.07.freebsd VB-96.18 Sun, libc
VB-95:07.abell VB-96.08.sgi VB-96.19 SGI, systour/ OutOfBox
VB-95:08.X_Authentication_Vul VB-96.09.freebsd VB-96.20 HP, Remote Watch
VB-95:09 - Hewlett Packard (ftp) VB-96.10.sco  

Cert Summaries:

CS-95:01 CS-96:01 CS-96:04
CS-95:02 CS-96:02 CS-96:05
CS-95:03 CS-96:03 CS-96:06 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

DFN-CERT (Germany)

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

England: t 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 .
Tel: +61 7 3365 4417 NASIRC (NASA Response Team)

The NASA team only offer support to NASA users, but do publish vulnerabilities found to FIRST members.
Tel. +1 800 762-7472 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

Previous CIAC notices, anti-virus software and other information are available at or . 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 with one (or more) of the following lines in the email body:

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):
A-01: Internet Attacks D-01: Novell NetWare Access Rights Vulnerability
A-02: The W.COM Worm affecting VAX VMS Systems D-02: Internet Attack Advisory
A-03: Tools to check the spread of the "WANK" Worm D-03: Patch Available for VAX/VMS MONITOR Vulnerability
A-04: New version of the "WANK" worm D-04: 18 New and Upgraded Security Patches For SunOS
A-05: Vulnerability in the SUN rcp utility D-05: Revised Hewlett-Packard NIS ypbind Vulnerability
A-06: Trojan horse in Norton Utilities for IBM PCs and clones D-06: Failure to disable user accounts for VMS 5.3 to 5.5-2
A-07: Information about a UNICOS Problem D-07: UNICOS Vulnerabilities
A-08: Information about a UNICOS Problem D-08: Vulnerability in VMS V5
A-09: Information about the WDEF virus D-09: OpenVMS VAX Patch Problems
A-10: Information about the PC CYBORG (AIDS) trojan horse D-10: November 17 Virus on MS DOS Computers
A-11: Problem in the Texas Instr. D3 Process Control System D-11: Sun Security Patches and Software Updates
A-12: DECNET Hacker Attack Alert D-12: UNICOS Vulnerabilities
A-13: Vulnerability in DECODE alias D-13: wuarchive FTP daemon vulnerability
A-14: Additional info on the vulnerability in the DECODE alias D-14: UNICOS Vulnerabilities
A-15: CIAC Bulletin A-15 D-15: Vulnerability in Cisco Routers used as Firewalls
A-16: Vulnerability in SUN sendmail program D-16: Vulnerability in SunOS expreserve Utility
A-17: Eradicating WDEF using Disinfectant 1.5 or 1.6 D-17: LIMITED DISTRIBUTION BULLETIN
A-18: Notice of Availability of Patch for SmarTerm 240 D-18: Solaris 2.x expreserve patches available
A-19: UNIX Internet Attack Advisory D-19: Wide-spread Attacks on Anonymous FTP Servers
A-20: The Twelve Tricks Trojan Horse D-20: Summary of SunOS Security Patches
A-21: Additional Information on Current UNIX Internet Attacks D-21: Novell NetWare LOGIN.EXE Security Patch
A-22: Logon Messages and Hacker/Cracker Attacks D-22: Satan Bug Virus on MS-DOS computers
A-24: Password Problems with Unisys U5000 /etc/passwd D-23: Cray UltraNet Security Vulnerability
A-25: The MDEF or Garfield Virus on Macintosh Computers D-24: SCO Home Directory Vulnerability
A-26: A New Macintosh Trojan Horse Threat--STEROID D-25: Automated Scanning of Network Vulnerabilities
A-27: The Disk Killer (Orge) Virus on MS DOS Computers D-26: Limited Distribution Bulletin
A-28: The Stoned (Marijuana or New Zealand) Virus on DOS E-01: Sun sendmail, tar, and audio Vulnerabilities
A-29: The 4096 (4k, Stealth, IDF, etc.) Virus on MS DOS E-02: Vulnerabilities in SGI IRIX Default Configuration
A-30: Apollo Domain/OS suid_exec Problem E-03: UNIX sendmail Vulnerabilities
A-32: SunView/SunTools selection_svc Vulnerability E-04: xterm Logfile Vulnerability
A-33: Virus Propagation in Novell and Other Network E-05: SunOS/Solbourne loadmodule and modload Vulnerability
A-34: End of FY90 Update E-06: Solaris System Startup Vulnerability
B-01: Security Problem on the NeXT Operating System E-07: UNIX sendmail Vulnerabilities Update
B-02: UNIX Security Problem with Silicon Graphics Mail E-09: Network Monitoring Attacks
B-04: VMS Security Problem :ANALYZE/PROCESS_DUMP E-11: Lotus cc:Mail Security Upgrade Available
B-05: HP-UX Trusted Systems 6.5 or 7.0, Authorization E-12: Network Monitoring Attacks Update
B-07: BITNET Worm E-13: Sun Announces Patches for /etc/utmp Vulnerability
B-08: Detection/Eradication Procedures for VMSCRTL.EXE Trojan Horse E-14: wuarchive ftpd Trojan Horse
B-09: Update on Internet Activity E-17: FTP Daemon Vulnerabilities
B-10: Patch for TIOCCON in SunOS 4.1 and 4.1.1 Available E-18: Sun Announces Patches for automountd Vulnerability
B-11: OpenWindows 2.0 selection_svc Vulnerability E-19: nVir A Virus Found on CD-ROM
B-12: GAME2 MODULE "Worm" on BITNET E-20: Trojan Attack on Chinon CD-ROM Drives
B-13: UNIX Security Problem with /bin/mail in SunOS E-23: Vulnerability in HP-UX systems with HP Vue 3.0
B-14: Additional Info. about /bin/mailin SunOS E-24: Security Patch Kits for ULTRIX, and OSF/1
B-15: Network intrus. through TCP/IP and DECnet Gateways E-25: BSD lpr Vulnerability in SGI IRIX
B-16: Virus Information Update E-26: UNIX /bin/login Vulnerability
B-17: Increasing Security on Your UNICOS System E-29: IBM AIX bsh Queue Vulnerability
B-18: MVS Security Problem with TSO Reconnect Facility E-30: Majordomo distribution list administrator vulnerabilities
B-19: Vulnerability in UNIX System V on 386/486 Platforms E-31: Sendmail -d and Sendmail -oE Vulnerabilities
B-20: Patch Available for SunOS in.telnetd E-32: KAOS4 Virus
B-21: Patch for SunOS 4.0.3 in.telnetd and in.rlogind E-33: Vulnerabilities in the SGI IRIX Help System
B-22: Attempts by Network Intruders to Obtain Passwords E-34: One_half Virus (MS-DOS)
B-24: Ultrix V4.0 and V4.1 Vulnerability F-01: SGI IRIX serial_ports Vulnerability
B-25: Configuration Problems in the NeXT Operating System F-02: Summary of HP Security Bulletins
B-26: Inconsis. Dir. and File Perms. in SunOS 4.1 and4.1.1 F-04: Security Vulnerabilities in DECnet/OSI for OpenVMS
B-27: sunsrc setuid Installation Problem F-05: SCO Unix at, login, prwarn, sadc, and pt_chmod Patches
B-28: AT&T System V Release 4 Patch for /bin/login F-06: Novell UnixWare sadc, urestore, and suid_exec
B-30: SunOS lpd Problem F-07: New and Revised HP Bulletins
B-31: CRAY UNICOS 6.0 and 6.1 accton vulnerability F-08: Internet Address Spoofing and Hijacked Session Attacks
B-32: Ultrix /usr/bin/mail Security Problem F-09: Unix /bin/mail Vulnerabilities
B-33: New SunOS lpd Problem F-10: HP-UX Remote Watch
B-33A: New SunOS lpd Problem -- Correction F-11: Unix NCSA httpd Vulnerability
B-35: Brunswick Virus on MS DOS Computers F-12: Kerberos Telnet Encryption Vulnerability
B-36: New patch available for /usr/ucb/telnet on ULTRIX F-13: Unix Sendmail Vulnerabilities
B-37: Security Problem with UNIX Trusted System Files F-14: HP-UX Malicious Code Sequences
B-38: Vulnerability in Silicon Graphics Inc. "IRIX" /usr/sbin/fmt F-15: HP-UX ´at' and ´cron' vulnerabilities
B-40: Virus distributed in PCNFS software fix for MS-DOS F-16: SGI IRIX Desktop Permissions Tool Vulnerability
B-41: Vulnerability in SunOS SPARC Integer Division F-18: MPE/iX Vulnerabilities
B-42: Security Issues with Macintosh System 7 F-19: Protecting HP-UX Systems Against SATAN
B-43: Vulnerability in ULTRIX DECnet-Internet Gateway F-20: SATAN
B-44: Automated tftp Probe Attacks on UNIX Systems F-21: Protecting SUN OS Systems Against SATAN
B-45: End of FY91 Update F-22: SATAN password disclosure
C-01: New TFTPD server available for IBM RS6000 systems F-23: Protecting IBM AIX Systems Against SATAN
C-02: Dir II Virus on MS DOS Computers F-24: Protecting SGI IRIX Systems Against SATAN
C-04: Vulnerability in the rdist utility on UNIX platforms F-25: Cisco IOS Router Software Vulnerability
C-05: Preliminary Information about SYSMAN.EXE Trojan F-26: OSF/DCE Security Hole
C-06: Security Problem in SunOS fsirand Program F-27: Incorrect Permissions on /tmp
C-07: Additional Information about the SYSMAN.EXE Trojan F-28A: Vulnerability in SunOS 4.1.* Sendmail (-oR option)
C-08: SunOS /usr/ucb/rdist patch G-01: Telnetd Vulnerability
C-10: OpenWindows V.3 patch G-02: SunOS 4.1.X Loadmodule Vulnerability
C-11: Novell Network Support Encyclopaedia Update Virus G-03: AOLGOLD Trojan Program
C-12: Hewlett Packard/Apollo Domain/OS crp Vulnerability G-04: X Authentication Vulnerability
C-13: NeXTstep NetInfo Configuration Vulnerability G-05: HP-UX FTP Vulnerability
C-15: Michelangelo Virus on MS DOS Computers G-06a Windows 95 Vulnerabilities
C-16: New Internet Intrusions Detected G-07: SGI Object Server Vulnerability
C-17: New Virus on Macintosh Computers: MBDF A G-08: splitvt() vulnerability
C-18: Vulnerability In AT&T /usr/etc/rexecd G-09: Unix Sendmail Vulnerability
C-19: Vulnerabilities in SAS© System 5.18 for VMS G-10: Winword & Excel Macro Viruses
C-20: SGI 3.3.X Pseudo-tty Vulnerability G-11: HP syslog Vulnerability
C-21: AIX REXD Daemon Vulnerability G-12: SGI ATT Packaging Utility Security
C-25: SunOS ypserv, ypxfrd, and portmap Patch G-13: Kerberos 4 Key Server Vulnerability
C-26: SunOS Environment Variables and setuid/setgid G-14: Domain Name Service Vulnerability
C-27: PKZIP Trojan Alert G-15: Sunsoft Demo CD Vulnerability
C-28: SunOS Security Patches G-16: SGI rpc.statd Program Security Vulnerability
C-29: Summary of SunOS Security Patches G-17: Vulnerabilities in Sample HTTPD CGIs
C-30: VAX/VMS Security Vulnerability in MONITOR G-18: Digital OSF/1 dxconsole Security Vulnerability
CIAC-01: Authentication Bypass in Sun 386i Machines G-19: IBM AIX rmail Vulnerability
CIAC-02: Columbus Day Virus G-20: Vulnerability in NCSA and Apache httpd Servers
CIAC-03: ULTRIX DECWindows Vulnerability G-21: Vulnerabilities in PCNFSD Program
CIAC-04: Jerusalem/Israeli/Friday the 13th Virus G-22: rpc.statd Vulnerability
CIAC-05: Security Holes in UNIX Systems G-23: Solaris NIS+ Configuration Vulnerability
CIAC-06: Patch for rwalld/wall G-24: FreeBSD Security Vulnerabilities
CIAC-07: Vulnerability Involving rcp and rdist G-25: SUN statd Program Vulnerability
CIAC-08: Vulnerability in the SunOS Restore Utility G-26: IRIX Desktop Permissions Panel Vulnerability
CIAC-09: Macintosh nVIR Virus G-27: SCO Kernel Security Vulnerability
CIAC-10: IBM PC Columbus Day (Datacrime) Virus G-28a: suidperl Vulnerability
CIAC-11: Telnet Trojan Horse  
CIAC-12: Patch for rcp and rdist  
CIAC-13: Macintosh and IBM PC NCSA Telnet Vulnerability  

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.

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. .

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 . See also 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):

[8lgm]-Advisory-1.UNIX.rdist.23-Apr-1991 [8lgm]-Advisory-16.UNIX.sendmail-6-Dec-1994
[8lgm]-Advisory-2.UNIX.autoreply.12-Jul-1991 [8lgm]-Advisory-16.UNIX.sendmail-6-Dec-1994.UPDATE
[8lgm]-Advisory-3.UNIX.lpr.19-Aug-1991 [8lgm]-Advisory-17.UNIX.sendmailV5-2-May-1995
[8lgm]-Advisory-4.UNIX.gopher.12-Feb-1992 [8lgm]-Advisory-18.UNIX.SunOS-kernel.4-Dec-1994
[8lgm]-Advisory-5.UNIX.mail.24-Jan-1992 [8lgm]-Advisory-19.UNIX.SunOS-kernel.1-Jun-1994
[8lgm]-Advisory-5.UNIX.mail.24-Jan-1992.PATCH [8lgm]-Advisory-20.UNIX.SunOS-sendmailV5.1-Aug-1995
[8lgm]-Advisory-6.UNIX.mail2.2-May-1994 [8lgm]-Advisory-21.UNIX.SunOS-sendmailV5.22-Aug-1995
[8lgm]-Advisory-7.UNIX.passwd.11-May-1994 [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995
[8lgm]-Advisory-7.UNIX.passwd.11-May-1994.NEWFIX [8lgm]-Advisory-23.UNIX.SunOS-loadmodule.2-Jan-1995
[8lgm]-Advisory-8.UNIX.SunOS-kernel.11-Nov-1994 [8lgm]-Advisory-24.UNIX.CERT.Advisory.CA-95:11.20-9-1995
[8lgm]-Advisory-9.UNIX.urestore.10-Feb-1993 [8lgm]-Advisory-25.UNIX.sun4c.locore.01-09-1995
[8lgm]-Advisory-10.UNIX.SCO-at.10-Feb-1992 [8lgm]-Advisory-26.UNIX.rdist.20-3-1996

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
The following is a list of bugs + exploitation scripts published on 12.2.96:

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 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) 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". 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: 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.

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 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 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 Operational Assurance 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. 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. Life-Cycle Assurance 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 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. 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. 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. 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.

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 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. 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 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. 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 Operational Assurance 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. 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. Life-Cycle Assurance 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 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. 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. 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. 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) 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:

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:

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

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. 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. 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 Example functionality class F-DX

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.

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.

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 ( ):

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.

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

previous  next  Title  Contents  Index         Previous     Next      Top   Detailed TOC      Last Update: 08 mai 2002