Previous Next Top Detailed TOC Last Update: 08 mai 2002
The following documents are copied locally:
What if your Machines are Compromised by an Intruder
Christopher Klaus of Internet Security Systems, Inc. <firstname.lastname@example.org>
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
- 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: 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.
- UNIX Programming tips, SunWorld.
- Code Signing: how-to
- Internet Webservers: best practices
Don't forget human rights in all of this security stuff..... especially privacy aspects. humanrights.html
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.
Virus Contacts (oldish):
Newsgroup: comp.virus PC Viruses
PC Virus Info. mailto:email@example.com
body= "SUB VIRUS-L firstname.lastname@example.org"
Macro virus list ftp://ftp.informatik.uni-hamburg.de/pub/virus/macro/
Response Team Contacts:
http://www.first.org [FIRST home page]
SWITCH CERT Switzerland mailto:email@example.com
CERT mailto:firstname.lastname@example.org *recommended*
CERT tools mailto:email@example.com
Other European Teams: see next section.
Australian CERT http://www.auscert.org.au/ [The Aussies are very up-to-date.]
CIAC mailto:firstname.lastname@example.org 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"
Risks forum mailto:email@example.com
Best of Security (bos) mailto:firstname.lastname@example.org
Security mailing lists (local copy)
SANS Network Security Digest mailto:email@example.com
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:firstname.lastname@example.org [not verified]
Sun "Customer Warning System" Security alert mailto:email@example.com , subject="subscribe CWS firstname.lastname@example.org", Tel. +1 415 688-9081
Sun sysadmin mailto:email@example.com
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
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 .
Hewlett Packard mailto:firstname.lastname@example.org
HP Security list mailto:email@example.com body="subscribe security_info"
HP-UX sysadmin mailto:firstname.lastname@example.org body="subscribe hpux-admin"
Newsgroup HP-UX news://comp.sys.hp.hpux
mailto:email@example.com , Tel. +1 719 592-4689
OSF/1 sysadmin mailto:firstname.lastname@example.org body="subscribe alpha-osf-managers"
BSDI sysadmin email@example.com
Santa Cruz Operation ftp://ftp.sco.com/SLS
Linux: Linux Emergency Response Team:
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
Email mailto:firstname.lastname@example.org , 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:email@example.com . For new issues, email mailto:firstname.lastname@example.org
Newsgroup news://comp.sys.sgi.bugs (IRIX bugs).
mailto:email@example.com , Tel. +1 800 237-5511
ftp://software.watson.ibm.com/pub/aix3 [Some AIX security patches]
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
NT Security Issues mailto:firstname.lastname@example.org
NTBugtraq mailto:email@example.com body= "SUB NTBUGTRAQ Your Name"
NT Security from ISS mailto:firstname.lastname@example.org body="subscribe ntsecurity"
NT, Explorer security www.ntsecurity.net *recommended*
Microsoft Security mailto:email@example.com www.microsoft.com/security
www.somarsoft.com/contents.htm [NT security]
www.iea.com/~daler/nt/faq/toc.html [NT frequently asked questions]
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 mailto:firstname.lastname@example.org "subscribe firewalls"
A digest is also available.
Security Hacking (full disclosure) groups:
Bug track discussion list mailto:email@example.com
Bugtraq database securityfocus.com/vdb
A large portion of the hacking scene has gone "white hat" (read commercial), for example:
Currently inactive groups:
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-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
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:firstname.lastname@example.org Computer Underground Digest
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
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
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:email@example.com . 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 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:firstname.lastname@example.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
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]
An Analysis Of Security Incidents On The Internet 1989-1995
Below is a complete list of advisories:
|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|
|VB-94:01.sco||VB-95:10 - Vulnerability in elm V2.4 PL 24||VB-96-11.free.bsd PPP|
|VB-94:02.dec||VB-96.01.splitvt||VB-96.12.free 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:06.cisco||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|
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.
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 email@example.com.
The German Federal Networks CERT co-ordinate security activities in Germany. Email firstname.lastname@example.org , tel. +49 040 5494-2262.
England: email@example.com t
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 .
Tel: +61 7 3365 4417
The NASA team only offer support to NASA users, but do publish vulnerabilities found to FIRST members.
Tel. +1 800 762-7472
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 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.
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:
|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|
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
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,
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
COAST (Computer Operations, Audit and Security Technology)
At Purdue university, COAST is a focal point for security research.
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 firstname.lastname@example.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 email@example.com.
The following is a list of bugs + exploitation scripts published on 12.2.96:
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.
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
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
In 1983, the American Department of Defense (DoD) (in fact the National Computer Security Centre), 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".
Infosec Awareness Office [to order documents]
+1 (410) 766-8729
Government Printing Office [to order the Infosec Systems & Security Catalogue]
+1 (202) 512-1800
+1 (410) 859-4458
The following is a direct extract from the Orange Book for classes C1 and C2:
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
184.108.40.206 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.
220.127.116.11 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.
18.104.22.168 Operational Assurance
22.214.171.124.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.
126.96.36.199.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.
188.8.131.52 Life-Cycle Assurance
184.108.40.206.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.)
220.127.116.11 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.
18.104.22.168 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.
22.214.171.124 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.
126.96.36.199 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
188.8.131.52 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.
184.108.40.206 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.
220.127.116.11 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.
18.104.22.168 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.
22.214.171.124 Operational Assurance
126.96.36.199.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.
188.8.131.52.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.
184.108.40.206 Life-Cycle Assurance
220.127.116.11.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.)
18.104.22.168 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.
22.214.171.124 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.
126.96.36.199 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.
188.8.131.52 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.
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.
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.
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
Netherlands Netherlands National Comsec Agency
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
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
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.
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.
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.
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
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.
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.
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".
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.
 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