Computer Security / Edition 3

Paperback (Print)
Rent
Rent from BN.com
$13.64
(Save 79%)
Est. Return Date: 10/20/2014
Buy Used
Buy Used from BN.com
$41.42
(Save 37%)
Item is in good condition but packaging may have signs of shelf wear/aging or torn packaging.
Condition: Used – Good details
Used and New from Other Sellers
Used and New from Other Sellers
from $32.68
Usually ships in 1-2 business days
(Save 50%)
Other sellers (Paperback)
  • All (16) from $32.68   
  • New (11) from $49.01   
  • Used (5) from $32.68   

Overview

A comprehensive and practical text and the perfect starting point for this subject ... 'Is this system secure?' seems, on the face of it, a straightforward question. Yet how one arrives at an answer is a process which poses a wide range of more complex questions which require a basic understanding of security mechanisms. Questions, such as: * Should protection focus on data, operations or users? * Whilst taking cast iron measures to build in security at one level, what does one do to prevent attackers gaining entry from a lower level?

Starting with basic definitions and concepts, the first section of the book goes on to outline the mechanisms located at the heart of the computer system, mechanisms which provide the basis for techniques used in all other branches of the system. The second section examines the security features found in operating systems such as UNIX and Windows NT, catalogues security breaches, and introduces the topic of security evaluation. A third section is devoted to issues associated with distributed systems, such as network - and Web - security and considers cryptography as an essential technique for such environments. The final section of the book is constructed around database security, discussing problems in multi-level security, and examining security problems in specific settings.

Written for self-study and course use, this book will suit a variety of introductory and more advanced security programmes for students of computer science, engineering and related disciplines. It meets a real need for a comprehensive textbook on the subject. Technical and project managers will also find that the broad coverage offers a great starting point fordiscovering underlying issues and provides a means of orientation in a world populated by a bewildering array of competing security systems.

This is not a handbook, encyclopedia or history of computer security; it is a publication on the technical aspects of computer security. Derived from a one-year post graduate course on information security, it discusses fundamental concepts, the application of security to current systems (UNIX and NT), distributed system security and the theoretical basis of database and multi-level security. Familiarity with operating systems, applications and security concepts at an advanced level is assumed. The author is associated with Microsoft Research Ltd, Cambridge, UK.

Read More Show Less

Editorial Reviews

From the Publisher
"Obviously, it is an excellent textbook either for high education or for advanced training programme on computer security.", Jianying Zhou, , Computer Communications 25/8/99#
Read More Show Less

Product Details

  • ISBN-13: 9780470741153
  • Publisher: Wiley
  • Publication date: 3/15/2011
  • Edition description: New Edition
  • Edition number: 3
  • Pages: 456
  • Sales rank: 1,255,767
  • Product dimensions: 7.30 (w) x 9.20 (h) x 1.00 (d)

Meet the Author

Dieter Gollmann, Microsoft Research, Cambridge, UK
Read More Show Less

Read an Excerpt

Chapter 8: How Things Go Wrong

8.8.5 Companion Virus

Filenames in DOS have the format name.extension. Typical extensions are .DIR, .COM, .EXE, etc. For added convenience, users do not have to specify the full filename of a program they want to execute and can omit the extension. If a user calls a program in this fashion, then DOS first looks for a .COM file with this name, then for a .EXE file, then for a .BAT file. A companion virus exploits this default searchpath. If the original program is a .EXE file, then a .COM file with the same name and containing a virus could be created and the infected program would be executed. This technique was used by the AIDS 2 virus.

Default searchpaths are convenient but dangerous. The same type of attack is possible in Unix by placing an infected file which has the same name as the target of infection in a directory which is searched first according to the PATH environment variable.

8.8.6 Macro Viruses

A virus that inserts itself into the boot process will be written in machine language and all early viruses operated at this level. However, this does not imply that every virus has to be written in machine language. As early as 1989, Harold Highland mentioned the possibility of a macro virus that attaches itself to a spreadsheet worksheet, a data file [67]. Macro viruses are particularly interesting, and damaging:

  • The virus is attached to a data file. Therefore, it will bypass integrity protection mechanisms targeting 'normal' executables (operating system, programs).
  • The virus is written in ahigh-level language. Therefore it is much more platform independent than a machine language virus.
  • Text documents are widely exchanged by email. This is an excellent medium for a virus to spread.

Macro viruses became reality in 1995. Microsoft's word processing system, MS-Word, allows users to tailor the environment their documents are displayed in. Formatting information, definitions for function keys and icons are all included in a macro file that comes with a text document. When this text document is opened the instructions in the macro are executed by MS-Word. When a new document is created the file NORMAL.DOT is used as a template for its macro.

A macro may seem to be simply an attachment to a data file but in reality it is a piece of executable code. However, users opening a file may not even he aware of the fact that they are running a program. All instructions available to write macros arc also available to virus writers who now can hide viral code in a macro file. The Concept macro-virus does exactly this. It infects .DOC and .DOT files. Once NORMAL.DOT has been infected. every newly created DOC file will automatically be infected.

A strict separation between program files and data files is an excellent basis for maintaining integrity in an environment where programs (to not change. A wordprocessor is a good example of such a program.

  • Data files may change but do not contain executable code, so they cannot damage the system.
  • Program files contain executable code but need not change. Integrity check values can be computed for all programs, saved in ROM, and any program can be checked before it is allowed to run

Macros were introduced to offer customers a more flexible word-processing system. At the same time, macros blur the distinction between data and program and create a new security problem.

8.8.7 Redirection of Interrupts

A virus is most damaging when it is executing in a privileged mode. To get into the privileged mode of a microprocessor, an interrupt (trap) has to be generated. The operating system then finds the address of the interrupt handier from the interrupt table. The interrupt table, and any similar structure, is therefore a prime target of attack. By changing the address of the interrupt handier, the operating system can be redirected to execute the virus, The virus makes itself memory resident as a TSR (terminate-and-stay-resident) program and is executed whenever the corresponding interrupt occurs.

This attack is particularly effective as it does not change the original interrupt handler and no integrity control mechanism checking this interrupt handier will detect the attack. A similar attack can be mounted by modifying entries in the file allocation table. An entry in the file allocation table (FAT) is modified so that it points to a virus, which in turn contains a link to the original file.

Removing a virus of this type may cause further damage. The virus is part of the link between table and file. If the virus is deleted, the link is broken and the file cannot be retrieved, at least not through the operating system.

8.8.8 Camouflage

A virus can try to avoid detection by various means. It can compress the infected program so that infection does not result in an increased use of memory. A stealth virus hides in a sector marked as bad in the FAT. Thus, other programs will nor-malty skip this sector when reading the disk. The virus can intercept interrupts to detect an attempt to detect its presence, e.g. an attempt to read the length, date, or checksum of a file it has infected. The virus will then return the original values. A polymorphic virus encrypts itself and uses a new key on each new infection to avoid detection by pattern recognition scanners. A multi-partite virus combines different types of infection to make detection more difficult. Slow infection viruses control the rate of infection to avoid immediate detection.

8.9 Anti-Virus Software

Viral attacks exploit a lack of integrity controls. To defend yourself, you therefore have to add those controls. Some of the available protection mechanisms are virus specific but mostly they address integrity in general. Your defensive strategy will have the following components:

  • Prevention: stops a virus from infecting your system.
  • Detection: detects a virus that has infected your system.
  • Reaction: restores your system to a clean state.

Administrative measures and user awareness are essential for successful virus protection.

8.9.1 Physical and Administrative Controls

Physical and administrative controls are an excellent way of preventing a virus from entering your system. Some of these measures are surprisingly simple. If you do not want to write to a floppy disk, put the write protection tab on and no virus will be able to infect it. If the operating system provides access control, use it properly. For example, set file permission on all applications on network servers to read and execute only.

Place controls at the point where a virus could enter your system. Test new software on quarantine machines where anti-virus software has been installed. Do your testing from an account with as few privileges as possible, e.g. Guest. Even better, use a sheep-dip (gateway) machine to run a virus scanner, checking all floppy disks entering an organization. If it decides that a floppy disk is clean, the disk receives a label and is now cleared for internal use. If the label is a sticker on the disk, it is up to user awareness to detect unauthorized disks within their organization. If an electronic label is written on the disk, then the machines within the organization can check for its presence and refuse unauthorized disks. Nowadays, fire-wall products often are equipped with a virus scanner to look for viruses coming in over the network.

Conduct regular virus checks and keep your anti-virus products up to date. Anti-virus software can be included in each user's login script. System utilities can automatically perform checks at predefined times. For example, in Unix the system manager can tell the cron utility when to run integrity check programs. Do not rely on a single protection mechanism; use a combination of techniques.

Contingency plans should be in place to know how to react to a virus incident. It is often claimed that inept reactions to a virus attack create more damage than the virus itself. Obviously, clean backups are essential when restoring your system after an attack. However, it is not uncommon that by the time a virus is detected, it has already found its way into all the backups kept.

8.9.2 Cryptographic Checksums

Cryptographic checksums are a standard integrity protection technique. A checksum is computed for a clean version of the file to be protected. This checksurn is stored in a secure place, ideally in a ROW e.g. on a CD. Whenever this file is used, the checksurn computed for its current version is compared with the stored checksum. Thus, any change to the original will be detected. Clearly, a checksummer does not have to know about a virus to detect its presence.

Checksummers are vulnerable whenever the checksum has to be recomputed, e.g. when a file changes or when the clean checksums have been lost. They are therefore more suitable for environments where only a fixed set of software tools is used than for organizations developing their own software. Also, checksummers do not indicate which virus caused the infection, making it more difficult to plan further actions once an infection has been detected....

Read More Show Less

Table of Contents

Ch. 1 Introduction 1
Ch. 2 Foundations of computer security 17
Ch. 3 Identification and authentication 35
Ch. 4 Access control 51
Ch. 5 Reference monitors 71
Ch. 6 Unix security 91
Ch. 7 Windows 2000 security 115
Ch. 8 Bell-LaPadula model 139
Ch. 9 Security models 153
Ch. 10 Security evaluation 169
Ch. 11 Cryptography 185
Ch. 12 Authentication in distributed systems 211
Ch. 13 Network security 233
Ch. 14 Software security 257
Ch. 15 New access control paradigms 283
Ch. 16 Mobility 307
Ch. 17 Database security 327
Read More Show Less

Customer Reviews

Average Rating 5
( 1 )
Rating Distribution

5 Star

(1)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)