Hide Notes 

Slide 2: OFFICIAL (ISC) GUIDE TO 2 ® THE SSCP ® CBK ®
Slide 3: OTHER BOOKS IN THE (ISC)2® PRESS SERIES Building and Implementing a Security Certification and Accreditation Program: Official (ISC)2® Guide to the CAPcm CBK® Patrick D. Howard ISBN: 0-8493-2062-3 Official (ISC)2® Guide to the SSCP® CBK® Diana-Lynn Contesti, Douglas Andre, Eric Waxvik, Paul A. Henry, and Bonnie A. Goins ISBN: 0-8493-2774-1 Official (ISC)2® Guide to the CISSP®-ISSEP® CBK® Susan Hansche ISBN: 0-8493-2341-X Official (ISC)2® Guide to the CISSP® CBK® Harold F. Tipton and Kevin Henry, Editors ISBN: 0-8493-8231-9
Slide 4: OFFICIAL (ISC) GUIDE TO THE 2 ® SSCP CBK ® ® Diana-Lynn Contesti, Douglas Andre, Eric Waxvik, Paul A. Henry, and Bonnie A. Goins Boca Raton New York Auerbach Publications is an imprint of the Taylor & Francis Group, an informa business
Slide 5: Auerbach Publications Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2007 by Taylor & Francis Group, LLC Auerbach is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works Printed in the United States of America on acid-free paper 10 9 8 7 6 5 4 3 2 1 International Standard Book Number-10: 0-8493-2774-1 (Hardcover) International Standard Book Number-13: 978-0-8493-2774-2 (Hardcover) This book contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission, and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity of all materials or for the consequences of their use. No part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www. copyright.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC) 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and registration for a variety of users. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe. Library of Congress Cataloging-in-Publication Data Official (ISC)2 guide to the SSCP CBK / Diana-Lynn Contesti ... [et al.]. p. cm. -- ((ISC)2 press series) Includes index. ISBN 0-8493-2774-1 (978-0-8493-2774-2 : alk. paper) 1. Computer networks--Security measures--Examinations--Study guides. 2. Electronic data processing personnel--Examinations--Study guides. I. Contesti, Diana-Lynn. TK5105.59.O44 2007 005.8--dc22 Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the Auerbach Web site at http://www.auerbach-publications.com 2007011467
Slide 6: Contents Foreword to the Official (ISC)2® Guide to the SSCP® CBK® . . . . . . . . . . xxv Introduction to the (ISC)2® SSCP® CBK® . . . . . . . . . . . . . . . . . . . . . . . . xxvii The SSCP Credential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxvii Global Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii The (ISC)2 SSCP CBK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix Organization of the Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi The Official (ISC)2 SSCP CBK Review Seminar . . . . . . . . . . . . . . . . . . . . xxxi SSCP Examination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxxii Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxxii Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii Domain 1 Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Paul A. Henry, CISSP Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Logical Access Controls in Terms of Subjects . . . . . . . . . . . . . . . . . . . . . . . 3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Group Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 User Account Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Password Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Account Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Access Rights and Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Logical Access Controls in Terms of Objects . . . . . . . . . . . . . . . . . . . . . . . . 6 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Object Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authentication Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authentication Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Multi-Factor Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Common Authentication Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . 7 Static Passwords and Passphrases. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 One-Time Password Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 v
Slide 7: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Asynchronous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Synchronous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Smart Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Biometrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Fingerprint Verification Technology . . . . . . . . . . . . . . . . . . . . . . . 10 Hand Geometry Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Eye Features — Retina Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Eye Features — Iris Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Facial Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Voice Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Signature Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Keystroke Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Biometric Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Remote Access Protocols and Applications . . . . . . . . . . . . . . . . . 13 Indirect Access and Authentication. . . . . . . . . . . . . . . . . . . . . . . . 14 Indirect Access and Authentication Technologies . . . . . . . . . . . 15 Single Sign-On (SSO). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Terminal Server Controller Access Control System (TACACS). . 16 Extended Terminal Server Controller Access Control System (XTACACS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Terminal Server Controller Access Control System Plus (TACACS+) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Remote Authentication Dial-In User Services (RADIUS) . . . . . . . 17 X.509. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Secure European System for Application in a Multi-Vendor Environment (SESAME) . . . . . . . . . . . . . . . . . . . . 20 Remote Terminal Solution — Secure Shell (SSH) . . . . . . . . . . . . . 21 Access Control Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Access Control Formal Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Bell–LaPadula Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Biba Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Clark–Wilson Formal Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Access Control Evaluation Criteria — Orange Book . . . . . . . . . . . . 24 Orange Book B Level — Mandatory Access Control . . . . . . . . . . . . 26 Orange Book C Level — Discretionary Access Control . . . . . . . . . . 27 Other Discretionary Access Control Considerations . . . . . . . . . . . . 29 Authorization Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Access Control Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Time-Based ACL Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Non-Discretionary Access Control . . . . . . . . . . . . . . . . . . . . . . . . 30 Role-Based Access Control (RBAC) . . . . . . . . . . . . . . . . . . . . . . . . 30 Rule Set-Based Access Control (RSBAC) . . . . . . . . . . . . . . . . . . . . 30 Content Dependent Access Control . . . . . . . . . . . . . . . . . . . . . . . . 31 Context-Based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 vi
Slide 8: Contents View-Based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Temporal Isolation (Time-Based) Access Control . . . . . . . . . . . . 33 Other Access Control Considerations . . . . . . . . . . . . . . . . . . . . . . . . 34 Capability Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Operating System Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Vulnerability Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Sample Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Domain 2 Security Operations and Administration . . . . . . . . . . . . . . . . . . . . . . . . . 43 Bonnie Goins, CISSP What Is “Security Administration”? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Fundamentals of Information Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 The A-I-C Triad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Monitoring and Maintenance of Appropriate Environmental Controls over Data and Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Policies and Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Compliance with Policy Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Security Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Information Security Compliance Liaison . . . . . . . . . . . . . . . . . . . . . . . 47 Remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Security Administration: Data Classification . . . . . . . . . . . . . . . . . . . . . . . 47 Marking and Labeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Assurance and Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Security Administration: Configuration Management . . . . . . . . . . . . . . . . 51 What Is Configuration Management (CM)? . . . . . . . . . . . . . . . . . . . . . . 51 Why Is CM Important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Change Control Roles in CM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Baseline Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Change Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Change Control Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 CCB Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Concept of Risk-Based, Cost-Effective Controls . . . . . . . . . . . . . . . . . . 54 Validation of Security Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Configuration Management Plan Development and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 vii
Slide 9: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Impact of Security Environment Changes . . . . . . . . . . . . . . . . . . . . . . . 55 Patches, Fixes, and Updates Validation . . . . . . . . . . . . . . . . . . . . . . . . . 55 Secure System Development Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 The System Development Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Risk Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Qualitative Risk Assessments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Quantitative Risk Assessments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Selecting Tools/Techniques for Risk Assessment . . . . . . . . . . . . . . . . . 62 Risk Assessment Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Identification of Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Identification of Threats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Determination of Likelihood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Determination of Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Determination of “Risk” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Reporting Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Countermeasure Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Risk Avoidance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Risk Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Risk Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Risk Acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Software Development Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 The Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Requirements Analysis and Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 66 System and Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Testing and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Operation and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 The Iterative Development Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 The Exploratory Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 The Rapid Application Development (RAD) Model . . . . . . . . . . . . . . . . . . 69 The Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 The Computer Aided Software Engineering (CASE) Model . . . . . . . . . . . 70 Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Security Management Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Creating the Security Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Security Policy Creation and Maintenance . . . . . . . . . . . . . . . . . . . . . . 73 Security Policy Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Security Procedure Development and Documentation . . . . . . . . . . . . 74 Organization Security Evaluation and Assistance . . . . . . . . . . . . . . . . . . . 74 The Protection Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Modes of Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 viii
Slide 10: Contents System High Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Compartmented Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Multilevel Secure Mode (MLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Operating Utilities and Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 The Central Processing Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Service Level Agreement Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Non-Disclosures (NDA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Non-Competition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Service Level Agreements (SLA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 User Security Awareness Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Security Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Security Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Security Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Security Awareness and Training Plan . . . . . . . . . . . . . . . . . . . . . . . . 81 Code of Ethics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 (ISC)2 Code of Ethics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 RFC 1087: Ethics and the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Acceptable Use Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Security Administration: Policies, Standards, and Guidelines . . . . . . . . . 83 Security Policy Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Implementing Security Requirements Guidance . . . . . . . . . . . . . . . . . . . . 84 Certification and Accreditation Process Concepts . . . . . . . . . . . . . . . . 84 Systems Accreditation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 System Certification Effort Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 British Standard (BS) 7799 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 ISO 17799 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 TEMPEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Security Administration: Security Control Architecture . . . . . . . . . . . 86 What Is a Security Control Architecture? . . . . . . . . . . . . . . . . . . . . . 86 Bell–LaPadula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Biba Integrity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Clark–Wilson Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Non-Interference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Access Control Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Information Flow Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Trusted Computer System Evaluation Criteria . . . . . . . . . . . . . . . . . . . 88 Goal of TCSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 TCSEC Classes of Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Information Technology Evaluation Criteria (ITSEC) . . . . . . . . . . . . 90 Security Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Target of Evaluation (TOE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Comparison of ITSEC to TCSEC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 ix
Slide 11: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® ITSEC Assurance Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Common Criteria: ISO 15408 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Security Best Practices Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Basic Security Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Least Privilege. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Separation of Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Rotation of Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Mandatory Vacation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Sample Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Domain 3 Analysis and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Eric Waxvik Section 1: Security Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Security Auditing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 What Are Security Audits? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Why Are Security Audits Performed? . . . . . . . . . . . . . . . . . . . . . . . . 101 Defining the Audit Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Audit Participant’s Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Defining the Audit Scope.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Defining the Audit Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Audit Data Collection Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Post Audit Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Security Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Why Have a Security Framework? . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Security Framework Guidelines and Standards . . . . . . . . . . . . . . . 108 Policy Organization Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Security Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Security Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Administrative Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Physical Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Technical Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Control Checks — Identification and Authorization . . . . . . . . . . . 112 Control Checks — User Access Control . . . . . . . . . . . . . . . . . . . . . . 113 Control Checks — Network Access Control (Firewalls and Filtering) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Control Checks — Intrusion Detection and Intrusion Prevention 114 Control Checks — Host Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Control Checks — Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Control Checks — System Hardening . . . . . . . . . . . . . . . . . . . . . . . 116 Control Checks — Unnecessary Services . . . . . . . . . . . . . . . . . . . . 116 Control Checks — Patching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Control Checks — Anti-Virus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Control Checks — Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 x
Slide 12: Contents Control Checks — Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Information Security Guidelines and Standards . . . . . . . . . . . . . . . 120 ISSA Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 ISO 17799 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Section 2: Security Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Security Testing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Why Is Security Testing Performed? . . . . . . . . . . . . . . . . . . . . . . . . 125 When Is Security Testing Performed? . . . . . . . . . . . . . . . . . . . . . . . 126 Who Should Perform Security Testing? . . . . . . . . . . . . . . . . . . . . . . 127 Security Testing Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Security Test Software Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Analyzing Testing Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Reconnaissance and Network Mapping Techniques . . . . . . . . . . . . . 131 Reconnaissance Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Social Engineering and Low-Tech Reconnaissance . . . . . . . . . . . . 131 Mid-Tech Reconnaissance — Whois Information . . . . . . . . . . . . . . 133 Mid-Tech Reconnaissance — DNS Zone Transfers . . . . . . . . . . . . 134 Network Mapping Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Network Host and Port Mapping Techniques . . . . . . . . . . . . . . . . . 136 System Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Vulnerability and Penetration Testing Techniques . . . . . . . . . . . . . . . 140 Vulnerability Testing Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Weeding Out False Positives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Host Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Firewall and Router Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Security Monitoring Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Security Gateway Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Wireless Networking Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 War Dialing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Password Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Penetration Testing Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Penetration Testing — General Examples . . . . . . . . . . . . . . . . . . . . 161 Penetration Testing High-Level Steps. . . . . . . . . . . . . . . . . . . . . . . . 162 Penetration Testing — NT Host Enumeration Example . . . . . . . . . 163 Penetration Testing Example Closing Notes . . . . . . . . . . . . . . . . . . 168 Section 3: Security Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Security Monitoring Concepts — Why Are Systems Attacked? . . . . 169 What Is an Intrusion? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Determining What Is Acceptable . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Security Monitoring for Everyday Life . . . . . . . . . . . . . . . . . . . . . . . 172 Security Monitoring for Computing Systems . . . . . . . . . . . . . . . . . 172 Why Is Monitoring Necessary? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Monitoring Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Other Monitoring Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 xi
Slide 13: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® IDS Monitoring Technologies and Methods . . . . . . . . . . . . . . . . . . . . . 176 Monitoring Technologies Overview . . . . . . . . . . . . . . . . . . . . . . . . . 176 NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 IDS as a Firewall Complement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 IDS Detection Methods Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Misuse Detection — Simple and Stateful Pattern Matching . . . . . 179 Misuse Detection — Protocol Analysis . . . . . . . . . . . . . . . . . . . . . . 180 Misuse Detection — Heuristical Analysis . . . . . . . . . . . . . . . . . . . . 181 Anomaly Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Target Monitoring Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Logging, Log Storage, and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Types of Log Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Choosing a Logging Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Enabling Secure Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Event Alerting and Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Techniques Used to Evade Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 188 Packet Floods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Packet Fragmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Slow Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Log Alteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Implementation Issues for Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 191 Criticality-Based Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Maintenance and Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Collecting Data for Incident Response . . . . . . . . . . . . . . . . . . . . . . . 194 Monitoring Response Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Response Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Sample Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Domain 4 Risk, Response, and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Eric Waxvik Section 1: Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Elements of Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Risk Management Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Risk Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Asset Valuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Threat Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Quantitative Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Qualitative Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Final Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 xii
Slide 14: Contents Countermeasure Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . 204 Cost-Benefit Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Return on Investment (ROI) Analysis . . . . . . . . . . . . . . . . . . . . . 206 Roles and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Frequency of Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Control Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Control Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Control Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Control Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Section 2: Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Business Continuity Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 The Importance of Business Continuity Planning . . . . . . . . . . . . . 213 Purpose of the BCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 IT Support of the Mission-Critical Functions during a Disaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Mission Critical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Phases of the BCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Project Management Phase Tasks . . . . . . . . . . . . . . . . . . . . . . . . 215 Business Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Critical Success Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 IT Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Conducting a BIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 BIA Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Project Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Vulnerability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Determination of Maximum Tolerable Downtime . . . . . . . . . 219 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Presentation of Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Reanalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Recovery Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Recovery Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Responsibilities for Business Recovery . . . . . . . . . . . . . . . . . . . 222 IT Responsibilities for Data and Information . . . . . . . . . . . . . . . 223 IT Responsibilities for Facility and Supply Restoration . . . . . . 224 IT Responsibilities for Network and Communications Restoration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 IT Responsibilities for User Restoration . . . . . . . . . . . . . . . . . . . 225 BCP Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 IT Responsibilities for Plan Development . . . . . . . . . . . . . . . . . . 226 IT BCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Testing, Verification, Validation, Maintenance . . . . . . . . . . . . . . . . 227 BCP Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 xiii
Slide 15: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Goal of Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Subscription Service Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Hot Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Cold Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Mobile Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Warm Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Service Bureaus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Reciprocal Agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 DRP Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Incident Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 The Need for Incident Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Computer Incident Response Issues . . . . . . . . . . . . . . . . . . . . . . 231 Threats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Incident Response Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Preparation and Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Computer Incident Response Policy Issues . . . . . . . . . . . . . . . . 235 Policy Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Policy Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Policy Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Incident Response Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Incident Response Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 The Incident Response Team (IRT) . . . . . . . . . . . . . . . . . . . . . . . . . 237 IRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Liaisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Viewing Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Response Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Correlation Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 IDS Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Containment Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Computer Incident Response Issues . . . . . . . . . . . . . . . . . . . . 244 Notification Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Investigation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Computer Evidence Issues . . . . . . . . . . . . . . . . . . . . . . . . . 246 Investigative Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Recognition of Evidence. . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Search and Seizure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 xiv
Slide 16: Contents Network Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Reviewing System Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Interviewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Terminating the Investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Recovery Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Response Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Follow-Up Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Record Keeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Final Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Computer Incident Response Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Electronic Forensics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Security and Recovery versus Electronic Forensics . . . . . . . . . 257 Media Analysis Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Media Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Hard Disk Examination: Step 1 — Sterile Media . . . . . . . . . . . . . . . 258 Hard Disk Examination: Step 2 — Legal Software . . . . . . . . . . . . . . 258 Hard Disk Examination: Step 3 — Physical Examination of the Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Hard Disk Examination: Step 4 — Avoid Altering the Evidence . . 260 Hard Disk Examination: Step 5 — Capture CMOS (RTC/NVRAM) and Date/Time Information. . . . . . . . . . . . . . . . . 260 Hard Disk Examination: Step 6 — Create an Exact Image . . . . . . . 261 Hard Disk Examination: Step 7 — Logically Examine the Image . . 261 Hard Disk Examination: Step 8 — Examine the Boot Record Data and User-Defined Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Hard Disk Examination: Step 9 — Recover and Examine All Deleted Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Hard Disk Examination: Step 10 — Create a Listing of All Files . . 263 Hard Disk Examination: Step 11 — Examine Unallocated Space for Lost or Hidden Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Hard Disk Examination: Step 12 — Examine File Slack . . . . . . . . . 264 Hard Disk Examination: Step 13 — Examine All User Created Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Hard Disk Examination: Step 14 — Unlock and Examine Password-Protected Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Hard Disk Examination: Step 15 — Create Printouts of All of the Apparent Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Hard Disk Examination: Step 16 — Examine Executable Files and Run Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Hard Disk Examination: Step 17 — Write the Forensic Analysis Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Floppy Diskette Examinations . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Limited Examinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 xv
Slide 17: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Incident Response Procedures (Specific to Windows NT/2000) . . . . . . 268 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Preparation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Containment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Forensic Duplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Steps in Aquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Recovery Response and Follow-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Video Forensics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Corporate Application of CCTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Analog Tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Frames versus Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Color versus Monochrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Digital CCTV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Aspect Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Legal Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Admissibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Section 3: Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Recovery Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Recovery Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 Processing and Information Gap. . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 Recovery Time Objective. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 Recovery Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Personnel Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Recovery Phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Phase 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Phase 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Phase 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Phase 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Phase 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Phase 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Phase 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Success Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 A Successful Recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Related Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 IT Management Role during Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 285 IT Management Role after Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Verify and Update Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 xvi
Slide 18: Contents References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Useful Web Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Sample Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Domain 5 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Doug Andre, CISSP Business and Security Requirements for Cryptography . . . . . . . . . . . . 294 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Non-Repudiation (Digital Signatures) . . . . . . . . . . . . . . . . . . . . . . . . . 296 Principles of Certificates and Key Management . . . . . . . . . . . . . . . . . . . 296 Issuing and Validating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Implementing Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Implementing IVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 X.509 v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 PKCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 DER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 BER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 RC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 RC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Wired Equivalent Privacy (WEP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 ANSI X9.17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 Concepts (e.g., Types, Formats) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Hash Function and Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Secure Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 SHTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 xvii
Slide 19: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Sample Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Domain 6 Networks and Telecommunications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Eric Waxvik Introduction to Networks and Telecommunications . . . . . . . . . . . . . . . . 321 The Basic OSI Model: Its Security Strengths and Weaknesses . . . . . 322 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Presentation Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Session Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 DOD TCP/IP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 Network Topologies and Their Security Issues . . . . . . . . . . . . . . . . . . 325 Star Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 Bus Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Ring Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Point-to-Point Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 WAN Access and Its Security Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Carrier Sense Multiple Access (CSMA) . . . . . . . . . . . . . . . . . . . . . . 328 Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 Carrier Sense Multiple Access with Collision Detection (CSMA/CD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 Carrier Sense Multiple Access with Bitwise Arbitration (CSMA/BA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 Dial-Up Access/Narrowband Access . . . . . . . . . . . . . . . . . . . . . . . . 328 Broadband Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 DSL Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Cable Internet Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 ISDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 PPPoE Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 VPN Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Network Protocols and Security Characteristics . . . . . . . . . . . . . . . . . . . 331 Network Protocols Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 TCP/IP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 IP Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 NAT/PAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 SMTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 xviii
Slide 20: Contents TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Network Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 PPP/SLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 PAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 CHAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Wide Area Network Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Integrated Services Digital Network (ISDN) . . . . . . . . . . . . . . . . . . 337 Digital Subscriber Lines (DSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 T-Carriers (T1, T3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Optical Carriers (OC-x) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 SDLC/HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Transport Layer Security Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 SSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 Application Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 PEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Data Communications and Network Infrastructure Components and Security Characteristics. . . . . . . . . . . . . . . . . . . . . . 342 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Physical Transmission Medias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Different Transmission Medias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 The Security Limitations of Physical Media . . . . . . . . . . . . . . . . . . 343 Coaxial Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 UTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Fiber Optic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Inherent Security Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 Wiring and Communication Closets and Data Centers . . . . . . . . . 346 The Enterprise Network Environment and Its Vulnerabilities . . . . . . 346 Local Area Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 Bridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Switches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Layer 2 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Layer 3 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Access Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 Firewalls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 VPN Termination Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 xix
Slide 21: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Routers and Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Router Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Clientless VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Remote Access Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Identification and Authentication for Remote Users . . . . . . . . . . . . . 353 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Different Types of Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Firewall Configuration Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . 354 Intrusion Detection Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Auditing and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 Different Types of IDS Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 Techniques for IDS Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Wide Area Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Circuit Switched versus Packet Switched WANs . . . . . . . . . . . . . . 358 Common WAN Infrastructures Used in Enterprise Networks . . . 358 Wireless Local Area Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Wireless Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 IEEE 802.11 Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 IEEE 802.11a Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 IEEE 802.11b Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 IEEE 802.11g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 IEEE 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 IEEE 802.11 Wireless LAN Equipment and Components . . . . . . . . 361 IEEE 802.15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 IEEE 802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 Wireless Access Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 Antennae. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 Antenna Configuration and Placement. . . . . . . . . . . . . . . . . . . . . 363 Wireless Network Interface Cards and Adapters . . . . . . . . . . . . . . 363 Inherent Security Vulnerabilities with IEEE 802.11x . . . . . . . . . . . . 363 802.11 Authentication and Its Weaknesses . . . . . . . . . . . . . . . . . . . 364 WEP Encryption and Its Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . 364 Passive Network Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Active Network Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 War Driving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 WLAN Jacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Securing 802.11 Wireless LANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 MAC Address Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 Authentication Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 WEP Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 IEEE 802.1x Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 VPN in a Wireless Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Wireless LAN Policy, Standard, and Procedures . . . . . . . . . . . . . . . 368 xx
Slide 22: Contents Need for Security Policies, Standards, and Procedures for the IT Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Securing the IT Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Domains of IT Security Responsibility . . . . . . . . . . . . . . . . . . . . . . . . . 370 User Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 Workstation Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 LAN Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 LAN-to-WAN Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 WAN Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 Remote Access Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 System/Application Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 Defining Standard and Enhanced Security Requirements . . . . . . . . . 373 Implementing Standard and Enhanced Security Solutions . . . . . . . . 373 References and Useful Web Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 Sample Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 Domain 7 Malicious Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 Diana-Lynn Contesti, CISSP Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 Information Protection Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 379 The A-I-C Triad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 A History of Computer Viruses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 File Infector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 Boot Sector Infectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Virus Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 Virus Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 Polymorphic Viruses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Stealth Viruses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Slow Viruses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Retro Viruses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Why Care? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Worms and Trojan Horses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 Trojan Horses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 Double File Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Other Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Denial of Service Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 TCP SYN Flood Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Smurf Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Distributed Denial of Service (DDoS) Attacks . . . . . . . . . . . . . . . . . 394 IP Fragmentation and RPC Null Fragment Attacks . . . . . . . . . . . . 396 Mail Bombing and Spamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 Pestware and Pranks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 xxi
Slide 23: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® ANSI Bombs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 Adware, Web Site Tracking Cookies (Trackware) . . . . . . . . . . . . . 398 Cookie Poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Homepage Hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Web Page Defacements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Brute Force Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Dictionary Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Hashed Password or Password-Verifier . . . . . . . . . . . . . . . . . . . . . . 400 Online versus Offline Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Salt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Logic Bombs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Ping of Death . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Spoofing Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 IP Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 Non-Blind Spoofing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 ARP Spoofing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 Man in the Middle Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 Denial of Service Attack (DoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 Active Content Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 Types of Mobile Code Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Attacks and Exploits Using Malformed Data . . . . . . . . . . . . . . . . . . . . 404 How Active Content Operates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 JavaScript and Visual Basic Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 Java Active Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 Structure and Focus of Malicious Code Attacks . . . . . . . . . . . . . . . . . 407 Uncoordinated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Coordinated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Directed Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Indirect Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Phases of an Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Reconnaissance and Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 DNS Commands and Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 ICMP and Related TCP/IP Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Using SNMP Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Port Scanning and Port Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Security Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Use of Spyware and Backdoor Trojans . . . . . . . . . . . . . . . . . . . . . . . . . 411 War Dialing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Access and Privilege Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 Password Capturing and Cracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 Malformed Data Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 Eavesdropping, Data Collection, and Theft . . . . . . . . . . . . . . . . . . . . . 413 Covert Channel Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 Hackers, Crackers, and Other Perpetrators . . . . . . . . . . . . . . . . . . . . . . . 414 What’s in a Name? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 xxii
Slide 24: Hackers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 White Hat (or Ethical) Hackers. . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Black Hat Hackers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Wannabes (also Wnnabes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 The “Cracker” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 System Crackers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 Script Kiddies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 Click Kiddies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 Phreakers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 Cyberpunts, Cyber-Criminals, and Cyber-Terrorists . . . . . . . . . 416 Where Do Threats Come From? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 Employees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 Social Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 Exploits from the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 Spyware and Adware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 How Can I Protect against These Attacks? . . . . . . . . . . . . . . . . . . . . . . 419 Application Defenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 Operating System Defenses (Hardening the OS) . . . . . . . . . . . . . . 421 Network Infrastructure Defenses . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 Incident Detection Tools and Techniques . . . . . . . . . . . . . . . . . . . . . . . . 423 Intrusion Detection Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 Anti-Virus Scanning Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 Types of Anti-Virus (Anti-Malware) Software. . . . . . . . . . . . . . . . . . . . 425 Network Monitors and Analyzers . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Content/Context Filtering and Logging Software . . . . . . . . . . . . . . 427 Other Techniques to Actively Detect and Analyze Hostile Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Classes of Honeypots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 Attack Prevention Tools and Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 428 Safe Recovery Techniques and Practices. . . . . . . . . . . . . . . . . . . . . . . 430 Develop a File Backup and Restoration Plan. . . . . . . . . . . . . . . . . . 430 Policy Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 Implementing Effective Software Engineering Best Practices . . . . . . 432 Sample Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 Appendix A Answers to Sample Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Domain 1: Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Domain 2: Security Operations and Administration . . . . . . . . . . . . . . . . 439 Domain 3: Analysis and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 Domain 4: Risk, Response, and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 446 Domain 5: Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 Domain 6: Networks and Telecommunications . . . . . . . . . . . . . . . . . . . . 454 Domain 7: Malicious Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 xxiii
Slide 25: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Appendix B Systems Security Certified Practitioners (SSCP®) Candidate Information Bulletin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 1 — Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 Key Areas of Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 2 — Security Operations and Administration . . . . . . . . . . . . . . . . . . . . . 462 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 Key Areas of Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 3 — Analysis and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Key Areas of Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 4 — Risk, Response, and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 Key Areas of Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 5 — Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 Key Areas of Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 6 — Networks and Telecommunications . . . . . . . . . . . . . . . . . . . . . . . . . 465 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 Key Areas of Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 7 — Malicious Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 Key Areas of Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 Sample Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 General Examination Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 Appendix C Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561 xxiv
Slide 26: Foreword to the Offical (ISC)2® Guide to the SSCP® CBK® Information Security is an increasingly important and critical component in the preservation, progress and stability of business in today’s world. Never have the pressures on corporations, governments and militaries been so widespread and multifaceted. While consumers and citizens are looking for the delivery of new and faster services, the legislatures of the world are placing more restrictions and oversight on the secure handling of information. The SSCP® is an exciting and practical solution for many organizations today. The SSCP provides a solid foundation of understanding of information security concepts and issues for many people throughout the organization. Whether as a system or network administrator, information systems auditor, computer programmer or systems analyst, or database administrator, the SSCP is an excellent introduction to beginning and advanced concepts in information security and is sure to be of benefit to many people throughout the organization. Information Security is a field of many opinions and perspectives; and the road to secure systems is often littered with tales of failures and unexpected lapses in security. All too often these failures are linked to a lack of understanding of the field of information security. This book will provide an excellent source of information, best practices, advice, and guidance that may prove invaluable in helping an organization to prevent errors, avert security breaches, and experience the loss of trust of consumers and officials. (ISC)2® has become recognized as the leader in the fields of information security and management. It is with great pleasure and respect that we provide you with this reference and welcome you to be a part of this fast moving and growing field. Whether as a new person in the field or looking to expand your knowledge, you will be sure to find the SSCP to be a practical, informative, and challenging step in your development. As you study this xxv
Slide 27: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® book and possibly prepare to sit for the SSCP (Systems Security Certified Practitioner) examination you are almost certain to venture into new areas of understanding or places that were formerly unfamiliar. This often leads the SSCP to pursue even more learning and development opportunities and we hope that you will consider contacting (ISC)2® for the opportunity to assist on volunteer and research projects. As a not-for-profit organization, (ISC)2 has been pleased to provide examinations and educational events, and to promote the development of information security throughout the world. You too can be a part of this by contacting us at www.isc2.org. Thank you for your interest in the field of information security and for purchasing this book. Welcome to an open door of opportunity and exciting new challenges. Tony Baratta, CISSP-ISSAP®, ISSMP®, SSCP Director of Professional Programs (ISC)2® xxvi
Slide 28: Introduction to the (ISC)2® SSCP® CBK® This first edition of the “Official (ISC)2® Guide to the SSCP® CBK®” marks an important milestone for (ISC)2. It acknowledges the important role that implementers of information security policy, procedures, standards, and guidelines play in an organization’s overall information security management infrastructure. Tacticians who implement technical countermeasures like firewalls, intrusion prevention systems, anti-virus software, access control technologies, cryptography, and a wide array of physical security measures are the real warriors on the front lines defending an organization’s digital assets. The (ISC)2 SSCP certification is the internationally recognized credential that allows those warriors to demonstrate their information security expertise, experience, and professionalism. The SSCP Credential The (ISC)2 Systems Security Certified Practitioner (SSCP) certification is today’s most important certification for information security practitioners. An SSCP has a demonstrated level of competence and understanding of the seven domains of the compendium of topics pertaining to the information systems security practitioner, the (ISC)2 SSCP CBK. The SSCP credential is ideal for those working toward or who have already attained positions such as systems or network administrator, senior network security engineer, senior security systems analyst, or senior security administrator. In addition, the SSCP has proven to be one of the best introductions to security principles for personnel that work in a role where security is not one of their primary responsibilities, such as application or Web programmers, information systems auditors, network, system and database administrators, and risk managers. The seven domains of the SSCP CBK include: • Access Controls • Security Operations and Administration xxvii
Slide 29: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • • • • • Analysis and Monitoring Risk, Response, and Recovery Cryptography Networks and Telecommunications Malicious Code The SSCP is awarded by (ISC)2 to information security practitioners who successfully pass the comprehensive examination based on the (ISC)2 SSCP CBK®, a compendium of global information security topics, possess at least one year of cumulative work experience in the field and subscribe to the (ISC)2 Code of Ethics. Once certified, the SSCP must maintain his or her certification through gathering Continuing Professional Education credits (CPEs). As a SSCP, you gain access to (ISC)2 services and programs that serve to support and enhance your growth throughout your information security career. These services and programs include: • • • • • • • Ongoing education Peer networking Forums Events Job postings Industry communications Speaking and volunteer opportunities Global Recognition (ISC)2’s commitment to developing global information security credentials was recognized in December 2005 by the representative for the International Organization for Standardization’s (ISO) in the United States, the American National Standards Institute (ANSI). ANSI accredited (ISC)2’s SSCP credential under ISO/IEC Standard 17024:2003 in the area of information security. The ISO/IEC 17024 standard is a new benchmark for general requirements for organizations that provide for certification of personnel. This certification helps verify that individuals in a particular field have the necessary knowledge, skills, and abilities to perform their work. The ANSI/ISO/IEC 17024 standard extends global recognition and acceptance of the SSCP, adding value to SSCP credential holders as they continue to be one of the most sought-after information security practitioners in the global market. The ANSI/ISO/IEC 17024 accreditation serves as a discriminator as employers and business partners seek the most qualified information security practitioners who hold accreditation credentials. Earning ISO/IEC 17024 ensures employers, customers, and citizens that information security xxviii
Slide 30: Introduction practitioners holding the SSCP credential have proven quality assurance skills and the global mobility so necessary in today’s marketplace. Educated, qualified, and certified information security practitioners are the key to protecting the critical infrastructure on which businesses and governments around the world operate. Employers in the public and private sectors can be confident that information security practitioners holding the (ISC)2 SSCP credential possess the necessary skills and experience to effectively manage and deploy information security programs and policies anywhere in the world. For SSCPs, this means their credential is recognized as an international standard in nearly 150 countries around the world as meeting a rigorous standard for qualifying and validating the skills and knowledge of information security practitioners. In today’s global economy and its continuing transformation by the information technology infrastructure and the Internet, accreditation means SSCPs can more easily traverse international boundaries and be recognized for their knowledge. The (ISC)² SSCP CBK The (ISC)2 SSCP CBK is a taxonomy — a collection of past, present, and future topics relevant to information security professionals around the world. The (ISC)2 CBK establishes a common framework of information security terms and principles that allows information security practitioners worldwide to discuss, debate, and resolve matters pertaining to the profession with a common understanding. The (ISC)2 SSCP CBK, like the other (ISC)2 CBKs, is continuously evolving. Every year the (ISC)2 SSCP CBK Committee, an international assembly of subject matter experts, reviews the content of the SSCP CBK and updates it with a list of topics from an in-depth job analysis survey of information security practitioners from around the world. These topics may address implementing new technologies, dealing with new threats, incorporating new security tools, and, of course, managing the human factor of security. The following are the seven domains of the SSCP CBK: • Access Controls — Access controls permit managers to specify what users can do, which resources they can access, and what operations they can perform on a system. Access controls provide systems managers with the ability to limit and monitor who has access to a system and to restrain or influence the user’s behavior on the system. Access control systems define what level of access that individual has to the information contained within a system based upon predefined conditions such as authority level or group membership. Access control systems are based upon varying technologies including passwords, hardware tokens, biometrics, and certificates, to name a few. xxix
Slide 31: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • Security Operations and Administration — Security operations and administration entails the identification of an organization’s information assets and the documentation required for the implementations of policies, standards, procedures, and guidelines that ensure confidentiality, integrity, and availability. Working with management, information owners, custodians, and users, the appropriate data classification scheme is defined for proper handling of both hardcopy and electronic information. • Analysis and Monitoring — Monitoring is an activity that collects information and provides a method of identifying security events, assigning a priority to these events, taking the appropriate action to maintain the security of the system, and reporting the pertinent information to the appropriate individual, group, or process. The analysis function provides the security manager with the ability to determine if the system is being operated in accordance with accepted industry practices, and in compliance with any specific organization policies and procedures. • Risk, Response, and Recovery — Risk management is the identification, measurement, and control of loss associated with adverse events. It includes overall security review, risk analysis, selection and evaluation of safeguards, cost benefit analysis, management decisions, safeguard implementation, and effectiveness review. Incident handling provides the ability to react quickly and put highly trained people at the forefront of any incident, and allows for a consistently applied approach to resolving the incident. Investigations include data collection and integrity preservation; seizure of hardware and software; evidence collection, handling, and storage; and reporting. Business Continuity Planning is planning that facilitates the rapid recovery of business operations to reduce the overall impact of the disaster, through ensuring continuity of the critical business functions. Disaster Recovery Planning includes procedures for emergency response, extended backup operations, and post-disaster recovery when the computer installation suffers loss of computer resources and physical facilities. • Cryptography — The ability of any organization to protect its information from unauthorized access or modification has become a major concern in recent years. The application of cryptography for the storage and transmission of information attempts to address these concerns. Cryptography is concerned with the protection of information by modifying the information to ensure its integrity, confidentiality, authenticity, and non-repudiation. Cryptanalysis is the opposite of cryptography, concerned with defeating the cryptosystem and violating the confidentiality or integrity of the protected data. • Networks and Telecommunications — In today’s global market place, xxx
Slide 32: Introduction the ability to communicate with others is a mandatory requirement. The networks and telecommunications domain encompasses the network structure, transmission methods, transport formats, and security measures used to maintain the integrity, availability, authentication, and confidentiality of the transmitted information over both private and public communications networks. • Malicious Code — The number and types of attacks using malicious code is increasing. The requirement for an individual or organization to protect themselves from these attacks is extremely important. The malicious code domain addresses computer code that can be described as being harmful or destructive to the computing environment. This includes viruses, worms, logic bombs, the Trojan horse, and other technical and non-technical attacks. While there are a variety of methods available to build a virus, many viruses are still targeted to a specific computing platform. With the availability of platform independent languages such as Perl, Active-X, and Java, it is becoming easier to write malicious code that can be run across different platforms. Organization of the Book The organization of this book follows the seven domains of the (ISC)2 SSCP CBK. The domains are represented in this book as seven chapters. Each chapter is followed by a series of self-assessment questions based upon the content of the preceding chapter. This book also follows the organization of the official (ISC)2 SSCP CBK Review Seminar. For candidates who choose to attend an official (ISC)2 SSCP CBK Review Seminar, this book should be used as supplementary material in conjunction with the SSCP CBK Review Seminar Student Manual, which is provided to all attendees. Although this book includes a broad range of important information security topics related to the SSCP CBK, the information security profession is so vast that candidates are advised to review other references as well. A list of (ISC)2 recommended reading for the SSCP CBK can be found at http://www.isc2.org. The Official (ISC)² SSCP CBK Review Seminar For candidates who are studying for the SSCP examination, (ISC)2 offers an official (ISC)2 SSCP CBK Review Seminar. The seminar is designed as an in-depth review of all seven domains of the SSCP CBK. It serves as an excellent tool by which candidates can review and refresh their knowledge of information security. During the three-day program, SSCP candidates will: • Complete a high-level overview of the seven SSCP CBK domains. xxxi
Slide 33: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • Identify areas for further self-study. • Survey the spectrum of understanding that distinguishes a certified IT security practitioner. The SSCP CBK Review Seminars are three-day, instructor-led, classroombased events held worldwide on a regular basis. Official (ISC)2 SSCP CBK Review Seminars are only conducted by (ISC)2 Authorized Instructors, each of whom is up-to-date on the latest information security-related developments and is an expert in the SSCP CBK domains. For more information, visit http://www.isc2.org. SSCP Examination The SSCP examination consists of 125 multiple choice questions. Candidates are given three hours to complete the examination. The questions are product-neutral and are designed to test a candidate’s understanding of information security fundamentals. Examination questions are written by professionals who have already obtained the SSCP certification. On an annual basis, (ISC)2 offers approximately 500 opportunities to take the examination in some 50 countries around the world. Acknowledgments (ISC)2 would like to thank the authors who contributed to this book, as well as the efforts of the many people who made this effort such a success. We trust that you will find this book to be a valuable reference that leads you to a greater appreciation of the important field of information security. xxxii
Slide 34: Authors Doug Andre, CISSP, SSCP is a security program manager and has over 15 years of information security and law enforcement experience. He has a proven track record assisting federal departments and agencies and private-sector clients with all phases of information security efforts. Diana-Lynn Contesti, SSCP, CISSP-ISSAP®, ISSMP® is the information security officer for DOFASCO Inc., in Hamilton, Ontario. This role involves the development and implementation of various security architectures, corporate security policy development, and implementation of virus and incident detection and response programs. Prior to working in information security, Diana-Lynn was involved in business continuity planning. Bonnie A. Goins, M.A. BS7799 Lead Auditor, CISSP, CISM, GIAC, ISS, NSA IAM, NSA IEM, ITIL Foundations is a nationally recognized subject matter expert in regulatory compliance consulting and crossmapping, information security management, and business continuity/disaster recovery planning. Her compliance, security, and business expertise has been put to use by many organizations to enhance, or to develop, world-class operations. She has over 17 years of experience in management consulting, information technology and security. Goins is called upon by executive management in global and national companies for her depth of knowledge and experience in information technology, regulatory compliance and security strategy development/refinement; business continuity, disaster recovery, and incident response planning; risk and security assessment methods; security program design, development and implementation; regulatory compliance initiatives, such as HIPAA, Sarbanes-Oxley, GLBA, NERC/FERC, FISMA, VISA CISP (PCI-DSS) and others; policy, procedure, and plan creation; technology and business process reengineering; secure network infrastructure design and implementation; and application security methods; and security/technology/regulatory training. She is the coauthor of the Digital Crime Prevention Lab, has authored chapters on security and regulatory compliance for national publications, and has been recognized in the Who’s Who in Information Technology. Paul A. Henry, MCP+I, MCSE, CCSA, CCSE, CFSA, CFSO, CISSP, CISM, CISA, ISSAP, CIFI Vice President, Strategic Accounts, Secure Computing® is one of the world’s foremost global information security experts, with more than 20 xxxiii
Slide 35: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® years experience managing security initiatives for Global 2000 enterprises and government organizations worldwide. At Secure Computing, Henry plays a key strategic role in launching new products and retooling existing product lines. In his role as vice president strategic accounts, Henry also advises and consults on some of the world’s most challenging and high-risk information security projects, including the National Banking System in Saudi Arabia, Department of Defense’s Satellite Data Project, USA, and NTT Data in Japan. Henry is a frequently cited by major and trade print publications as an expert on both technical security topics and general security trends, and serves as an expert commentator for network broadcast outlets such as NBC and CNBC. In addition, Henry regularly authors thoughtful leadership articles on technical security issues, and his expertise and insight help shape the editorial direction of key security publications such as the Information Security Management Handbook, where he is a consistent contributor. Henry serves as a featured and keynote speaker at network security seminars and conferences worldwide, delivering presentations on diverse topics including network access control, cyber crime, DDoS attack risk mitigation, firewall architectures, computer and network forensics, enterprise security architectures, and managed security services. Eric Waxvik, SSCP, has been in the IT industry for 17 years, the majority of which have been in the computer security arena. As the former chief of the Information Assurance Defense for the Automated System Security Incident Support Team (ASSIST), now know as the Department of Defense Computer Emergency Response Team (DoD CERT), he was responsible for conducting and overseeing the Vulnerability Analysis and Assistance Program (VAAP), the Virus Team, and the Incident Response Team, which were responsible for investigations for the entire Department of Defense. He has since moved on to the private sector, where he consults with Fortune 500 companies and the federal government on the latest security recommendations and solutions. xxxiv
Slide 36: Domain 1 Access Controls Paul A. Henry, CISSP Introduction Access controls are those systems that provide for the ability to control “who” can do specifically “what” with respect to data, applications, systems, networks and physical spaces. In the simplest of terms (and in a perfect world), an access control system grants system users only those rights necessary for them to perform their respective jobs. The term “access controls” is very broad in nature and can include everything from a simple password authentication that allows a user to access an e-mail account to a biometric retina scanner that unlocks the door to a critical data center. There are three principle components of access control: 1. Access control systems • Policies that define the access control rules • Procedures that determine how the rules will in fact be enforced • Technologies that actually accomplish the enforcement objectives 2. Access control subjects • Authorized users • Unauthorized users • Applications • Processes • Systems • Networks 3. Access control objects • Data • Applications • Systems • Networks • Physical space (i.e., the data center) In the simplest of terms, access control systems control how an access control subject may interact in some manner with an access control object. In order for any access control subject to obtain access to an access control object, there are typically three steps that must accomplished (shown in Figure 1.1). 1
Slide 37: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Identification Authentication Authorization Figure 1.1 Identification Identification asserts a unique user or process identity and provides for accountability. Identification of an access control subject is typically in the form of an assigned username. This username could be public information whether intentional or not. For example, in most networks the username that identifies the user for network access is also the identification used as the e-mail account identifier. Hence, all one would have to do to determine the account holder’s username would be to know the account holder’s email address. An access control that relied on the username alone to provide access would be an ineffective access control. In order to prove that the individual who presented the username to the access control is the individual that the username was assigned to, a secret is shared between the access control system and the respective user. This secret is the user’s password and is used to authenticate that the user that is trying to gain access is in fact the user that owns the rights associated with the respective identification. Authentication Authentication is the process of verification that the identity presented to the access control system belongs to the party that has presented it. In network authentication the identification of the user is authenticated using 2
Slide 38: Access Controls a secret password that only the user would know. This would be referred to as simple authentication. There are more complex authentication methodologies, such as “dual factor authentication,” that not only require the secret that the user knows but also requires another layer of authentication in the form of something the user “has” in his or her possession — such as a security token or something the user ”is” as in the case of biometric authentication a finger print or retina scan. We will discuss complex authentication methodologies such as dual factor later in this chapter. Again, the objective of authentication is to prove the identity of the user that is asking for some type of access from the access control system. Authorization Authorization is granted to the access control object only after the access control subject has been properly identified and authenticated. The access control system determines what specific access rights are granted to the access control subject based upon the rules within the access control system. Typically, the rules that are applied are directly related to the identification of the individual requesting access. Authorization can be as simple as allowing access to a specific account in an email application after the access control subject has been properly authenticated. In more complex access control system rules the authorization of access may also take time into consideration, i.e., the subject is allowed access to the e-mail application for his account but only during normal office hours. Another complex example access control rule could take the user’s physical location at the time of authentication into consideration and require that the user authenticates from an IP address or location inside of the network during normal working hours using a username and password, but, when access is requested by the access control subject from outside of the network across the public Internet, the access control rules could require the use of two factor authentication before permitting access to the user’s e-mail account. Logical Access Controls in Terms of Subjects Requirements An access control subject is an active entity and can be any user, program, or process that requests permission to cause data to flow from an access control object to the access control subject or between access control objects. The authorization provided to the access control subject by an access control system can include but is not limited to the following considerations: • Access control subject — Temporal — time of day, day of request — Locale from where the access control subject authenticated 3
Slide 39: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® — Inside or outside of the network — Password or token utilized — An individual access control subject may have different rights assigned to specific passwords that are used during the authentication process • Access control object — Data content of the object — The access control subject may be restricted from accessing all or part of the data within the access control object because of the type of data that may be contained within the object — Transaction restrictions may also apply The attributes of a subject are referred to as privilege attributes or sensitivities. When these attributes are matched against the control attributes of an object, privilege is either granted or denied. In a typical access control system, additional subject specific requirements may include: • A secure default policy should be applied to any newly created subject. • The attributes of the subject should not be expressed in terms that can easily be forged such as an IP address. • The system should provide for a default deny on all permissions for the subject, thereby requiring access to any object be explicitly created by an administrator. • In the absence of policy for a given subject, the default policy should be interpreted as default deny. • A user ID should remain permanently assigned to a subject. Group Profiles The configuration of privileges in access control for an individual subject affords maximum granularity. In systems with perhaps hundreds or thousands of users, this granularity can quickly become a management burden. By incorporating multiple subjects with similar permissions (e.g., job titles) within a group, the granularity is thereby coarsened and the administration of the access control system is simplified. User Account Maintenance Password Administration The selection, management, and auditing of passwords are critical components of the access control system. Current technology access control systems provide for automated password administration to reduce the managerial burden associated with password administration. 4
Slide 40: Access Controls Password selection is typically based on the following criteria: • Minimum password length • Required usage of letters, case, numbers, and symbols in the makeup of the password • Password expiration (typically 90 days) • Restrictions on the reuse of a user’s previous passwords The regular auditing of passwords can provide for increased security by reducing the potential for unauthorized access. Many legacy access control systems that are still in use today provide little password administration automation. Often, this results in high administrative workload or, when neglected, in unauthorized access. Account Administration The account administration of an access control system is a complex task that includes setting the rights and or privileges of all user, system, and services accounts. Typical account administration tasks include, but are not limited to: • Account creation — Authorizations, rights, and permissions • Maintenance — Resetting of locked out accounts — Auditing of passwords to validate adherence to policy • Account termination • Disabling account — Temporary renaming of the account to allow for limited management access — Final closure of the account Access Rights and Permissions It is most common for the owner of the data (object) to determine the permissions and access rights to the data for a specific account (subject). The principle of least privilege is most often used in configuring the rights and permissions for an account. Effectively, only those rights and privileges necessary for the account owner to perform their respective duties are assigned. The use of least privilege in the assignment of access rights and permissions can contribute to a higher level of security by mitigating the risk of abuse of authorized access. Monitoring All changes to accounts within the access control system should be logged and reviewed on a regular basis. Particular attention should focus on any newly created accounts as well as any escalation of the privileges for an existing account to make certain that the new account or the increased privileges are authorized. The regular monitoring of changes to accounts can help to mitigate the risk of misuse or unauthorized access. 5
Slide 41: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Logical Access Controls in Terms of Objects Requirements An access control object is a passive entity that typically receives or contains some form of data. The data can be in the form of a file, a program, or may be resident within system memory. Typical access control object considerations can include but are not limited to the following: • Restrict access to operating system configuration files and their respective directories to authorized administrators. • Disable write/modify permissions for all executable files. • Ensure that newly created files inherit the permissions of the directory in which they were created. • Ensure that subdirectories cannot over ride the permissions of parent directories unless specifically required by policy. • Log files should be configured to only permit appending data to mitigate the risk of a log file’s contents being purposely deleted or overwritten by a malicious user or process. • Encryption of data at rest can afford additional security and should be a consideration in the determination of the policies for access control objects. Object Groups The configuration of privileges to access an individual object affords maximum granularity. It is not uncommon today for the number of objects within an access control system to number in the tens or even hundreds of thousands. While configuring individual objects affords maximum control, this granularity can quickly become an administrative burden. It is a common practice to assign the appropriate permissions to a directory, and each object within the directory inherits the respective parent directory permissions. By incorporating multiple objects with similar permissions or restrictions within a group or directory, the granularity is thereby coarsened and the administration of the access control system is simplified. Authentication Implementation Authentication Methods Authentication validates the identity of the access control subject. It does so by using something unique that the access control subject either knows, has, or is. Authentication can be implemented in many ways but there are three basic types of authentication: 6
Slide 42: Access Controls • Knowledge-based — something that you know — Password or passphrase • Token-based — something that you have — Synchronous or asynchronous Token — Smartcard • Characteristic-based — something that you are — Biometric — Behavioral As you move down the list of available techniques, security assurance is increased. Simply put, knowledge-based devices can be more easily defeated than characteristic-based devices. Multi-Factor Authentication For many years knowledge-based authentication in terms of passwords was the most common methodology in use in access control systems. Improved Brute Force and Dictionary attacks against passwords has effectively rendered these knowledge based methodologies obsolete. In October 2005 the Federal Financial Institutions Examination Council (FFIEC) provided a recommendation (http://www.ffiec.gov/pdf/authentication_guidance.pdf) to U.S. banks that included, in part, a requirement to replace passwords — single factor authentication with multifactor authentication. The recommendation clearly pointed out that passwords alone were simply no longer a secure methodology for authenticating users in the current Internet environment. The best practice in access control is to implement at least two of the three common techniques for authentication in your access control system: • Knowledge-based • Token-based • Characteristic-based Common Authentication Methodologies Static Passwords and Passphrases Static passwords/passphrases are still the most common authentication methodology in use today. Unfortunately for the community at large, they have also proven to be one of the weakest links in network security. Lists of default static passwords for network and security products are freely downloadable on the public Internet. Furthermore hackers no longer have to take the time to brute force (guess) static passwords because tools such as Rainbow Tables (precomputed hash database) have made determining passwords as simple as looking up the respective hash in a database to determine the underlying password. 7
Slide 43: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® The weaknesses in passwords/passphrases are many and include but are not limited to: • Leakage during use — Stolen by Spyware — Stolen with key logger — Stolen by malicious fake Web site (phishing) • Leakage during login — Password sniffing — i.e., Cain & Able or LophtCrack are able to sniff passwords on the wire during login • Leakage during password maintenance — While password is being generated — While password is being distributed — While password is in storage In the opinion of this author, the use of static passwords/passphrases as a security mechanism has been rendered obsolete. One-Time Password Token One-time password methodologies are typically implemented utilizing hardware or software token technology. The password is changed after each authentication session. This effectively mitigates the risk of shoulder surfing or password sniffing as the password is only valid for the one session and cannot be reused. Asynchronous A popular event driven — asynchronous token — from Secure Computing called SafeWord provides a new one-time password with each use of the token. While it can be configured to expire on a specific date, its lifetime depends on its frequency of use. The token can last from five to ten years and effectively extend the time period typically used in calculating the total cost of ownership in a multifactor authentication deployment. In the use of an asynchronous one-time password token, the access control subject typically executes a five-step process to authenticate identity and have access granted: 1. The authentication server presents a challenge request to the access control subject. 2. The access control subject enters the challenge into his or her token device. 3. The token device mathematically calculates a correct response to the authentication server challenge. 4. The access control subject enters the response to the challenge with a password or PIN number. 5. The response and password or PIN number is verified by the authentication server and, if correct, access is granted. Synchronous In the use of a synchronous token, time is synchronized between the token device and the authentication server. The current time value is enciphered along with a secret key on the token device and is pre8
Slide 44: Access Controls sented to the access control subject for authentication. A popular synchronous token from RSA called SecureID provides for a new 6–8 digit code every 60 seconds; it can operate for up to four years and can be programmed to cease operation on a predetermined date. The synchronous token requires fewer steps by the access control subject to successfully authenticate: 1. The access control subject reads the value from his or her token device. 2. The value from the token device is entered in the log-in window along with the access control subject’s PIN. 3. The authentication server calculates its own comparative value based on the synchronized time value and the respective access control subject’s PIN. If the compared values match, access is granted. The use of a PIN together with the value provided from the token helps to mitigate the risk of a stolen or lost token being used by an unauthorized person to gain access through the access control system. Smart Card Smart cards are another form of “what-you-have” security devices. Smart cards employ a microprocessor that contains detailed information about the access control subject that is accessible (readable) with a proximity or contact device. Currently there are two types of smart cards: • Proximity (RF based) smart cards — Use an RF device to read the access control subject’s smart card data whenever the card is within proximity of the reader • Contact based smart cards — Require the cardholder to insert the card into a card reader to obtain the access control subject’s smart card data Memory Card technology today is being used primarily to secure physical access to a facility. The memory card can allow the access control system to trace an individual’s movement throughout a secured facility. Benefits of Smart Cards • • • • • • Can securely and portably store personal information Critical computations are isolated and performed within the card Can offer authentication across a large enterprise Can securely store encryption keys Able to execute encryption algorithms within the card User authentication is done within the card reader thereby mitigating the risks associated with a nontrusted path log-in transmission Biometrics Biometrics, “what-a-person-does” or “what-a-person-is,” allows for the confirmation of an individual’s identity based on either a physiological condition such as a fingerprint, retina scan, or a behavioral characteristic, such as keystrokes, speech recognition, or signature dynamics. 9
Slide 45: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Types of biometric devices include those that recognize: • Physical traits — Fingerprints — Hand geometry — Eye features — retina scan or iris scan — Facial recognition • Behavioral traits — Voice pattern — Signature dynamics — Keystroke dynamics Fingerprint Verification Technology Fingerprint verification typically requires seven characteristics or matching points in order to either enroll a new access control subject or to verify an existing access control subject. The task is not as difficult as it may seem as the human finger contains 30–40 characteristics or matching points. The fingerprint reader does not store an image of the fingerprint. Rather, it creates a geometric relationship between the characteristics or matching points and stores and then compares that information. Hand Geometry Technology Hand geometry verification is typically accomplished by building a five-element array of finger lengths determined from scanned matching points at the base and end of each finger. The stored five-element array is compared to a new hand scan and a mathematical calculation is performed to determine the geometric distance between the respective arrays. Eye Features — Retina Scan The retina scan is one of the oldest and most accurate biometric authentication methodologies. Dating back to 1930, it was recognized that each human retina had unique characteristics; however, it was 1984 before the first commercial retina scanner was released to the public. Traditionally, the retina scan has been reserved only for the most secure application of physical access control systems. The retina scan simply maps the blood vessels in the back of the eye and only requires ten or so seconds to complete a scan. There is no known technology that can forge a retina scan signature and, as the blood vessels quickly decay upon death, a retina scan on a dead individual will not create the same signature as that of the live individual. Hence, a retina scan prevents unauthorized access. Eye Features — Iris Scan Iris scanning is based upon scanning the granularity of the richly detailed color bands around the pupil. The color bands are well defined at birth and change little over the subject’s lifetime. The typical iris scanner maps nearly 247 variables in the iris and can do so at a distance of 19 to 20 inches. This makes the iris scanner potentially more accurate than a fingerprint (with only 40 to 80 characteristics) and is less obtrusive than a retina scanner as it does not require the same close proximity to the reading device or a light shining into the eye. 10
Slide 46: Access Controls Facial Recognition Like the fingerprint reader and hand geometry devices, facial recognition uses a mathematical geometric model of certain landmarks of the face such as the cheekbone, tip of the nose, and eye socket orientation and measures the distance between them. There are approximately 80 separate measurable characteristics in the human face, but most facial recognition systems only rely upon 14 to 22 characteristics to perform their recognition. Voice Recognition Voice recognition works by creating a database of unique characteristics of the access control subject’s voice. The access control subject then simply speaks at or near a microphone and the access control device compares the current voice pattern characteristics to the stored characteristics to determine if access is to be granted. Biology, not technology, is the issue with voice recognition. As the subject ages, the characteristics of the voice naturally change. Voice characteristics can change under stress, and during an emergency situation the access control subject could be denied access simply because of the stress he or she was under at that moment. Further, it is possible to create an error simply by altering the inflection of a given phrase. Voice recognition is an inexpensive methodology to implement, but, because of the high probability of error, it is best used to compliment another more accurate technology such as iris scanning and not to be relied upon as a primary access control device. Signature Analysis The handwritten signature is unique to each individual. Most access control signature analysis access devices use a 3D analysis of the signature that includes both the pressure and form of the signature. Signature analysis dynamically measures the series of movements that contain biometric characteristics, such as acceleration, rhythm, pressure, and flow. Signature analysis access control devices have become popular with credit card merchants for authorization of credit card transactions. Keystroke Dynamics Keystroke dynamics, like the other forms of authentication devices mentioned above, rely upon characteristics that are unique to an individual. In the case of keystroke dynamics, it is the characteristics of the access control subject as the username and password (actually passphrase) is typed on the key board. The normal characteristics of the individual are learned over time and typically can be enrolled with six or eight samples. The individual characteristics used by the typical keystroke analysis device include, but are not limited to: Length of time each key is held down Length of time between keystrokes Typing speed Tendencies to switch between a numeric keypad and keyboard numbers • Keystroke tendencies involved in capitalization • • • • 11
Slide 47: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® The accuracy of keystroke dynamics can be easily impacted by hand injuries, fatigue, arthritis and perhaps temperature. Hence, while keystroke dynamics is regarded as the lowest cost authentication mechanism it cannot yet be used reliably in a single factor or perhaps two factor (using passphrase) authentication methodology and is better suited to compliment another technology such as iris scanning in a two factor authentication scheme. Biometric Accuracy Biometric accuracy is measured by two distinct rates: • Rate of false acceptance — false acceptance rate (FAR) — Referred to as type two error • Rate of false rejection — false rejection rate (FRR) — Referred to as type one error The actual methodologies of the measurement of accuracy may differ in each type of biometric device, but you can obtain a good comparative accuracy factor by looking at the intersection point at which the type one error rate equals the type two error rate as shown in Figure 1.2. This value is commonly referred to as the cross-over error rate (CER). The biometric device accuracy increases as the cross over value becomes smaller as shown in Figure 1.3 (derived from a report on the comparison of biometric techniques by Thomas Ruggles http://www.bio-tech-inc.com/bio.htm). Operating Curve crossover point FRR crossover error rate FAR less sensitive Sensitivity Parameter Figure 1.2 more sensitive 12
Slide 48: Access Controls Biometric Cross Over Accuracy Retinal Scan 1:10000000 Iris Scan 1:131,000 Fingerprint 1:500 Hand Geometry 1:500 Signature Dynamics 1:50 Voice Dynamics 1:50 Figure 1.3 Comparison of Biometrics Characteristic Ease of Use Error incidence Accuracy User acceptance Required security level Long-term stability Fingerprints High Dryness, dirt, age High Medium High High Hand Geometry High Hand injury, age High Medium Medium Medium Retina Low Glasses Very High Medium High High Iris Medium Face Medium Signature High Changing signatures High Medium Medium Medium Voice High Noise, colds, weather High High Medium Medium Lighting, age, Poor Lighting glasses, hair VeryHigh Medium Very High High High Medium Medium Medium Figure 1.4 A further comparison of biometric technologies is provided in Figure 1.4, which has been derived from data contained within an article entitled “A Practical Guide to Biometric Security Technology” by Simon Liu and Mark Silverman (IEEE 2005). In reusable password authentication, the access control subject had to remember a perhaps difficult password, in token based authentication the access control subject had to retain possession of the token device. In biometric characteristic based authentication, the actual access control subject is the authentication device. Remote Access Protocols and Applications Access control system authentication is typically accomplished in either one of two architectures: • Decentralized — The access control subject credentials are stored on the local device. This architecture is common on stand alone devices such as a home PC or some physical access control devices. — While local authentication offers easy system maintenance in comparison to a centralized authentication methodology, it can be difficult to add additional access control objects, therefore, it is most often regarded as not scalable. • Centralized — The access control subject credentials are stored on a central server. This architecture is common in network environments. 13
Slide 49: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® — The centralized server can be positioned within a protected network and, therefore, offers additional security. — Centralized authentication allows both additional access control subjects and access control objects to be added, thereby making this methodology more scalable. — Popular centralized implementations are RADIUS, TCACS+, and Kerberos. — Strength is consistent administration of creating, maintaining, and terminating credentials, but weaknesses include credentialing delays and single point of failure. It must be noted that in either architecture, physical access to the server or device that stores the access control subject’s credentials is a common goal of a malicious hacker or insider and can be disastrous. Indirect Access and Authentication Indirect access and authentication occurs when the user is not directly authenticating to a given application. The user authenticates to a middle tier such as a RADIUS server or a firewall that is effectively used as an authentication proxy. The middle tier then acts on the user’s behalf to impersonate the user when authenticating to protected applications. Indirect access authentication is commonly used in providing authentication services for both internal users within a large enterprise as well as remote clients connecting to the internal network. It is important to define the terminology used in describing some the inherent threats to indirect access and authentication prior to our discussion of the access control technologies used for indirect access and authentication. Remote threats to indirect access and authentication include: • War dialing — Sequential dialing of multiple (or all of the) telephone numbers within a telephone exchange in an effort to find telephone numbers that offer modems • Brute force attacks — Trying combinations of usernames and passwords from a dictionary or list in an effort to obtain unauthorized access • Sniffing — Gaining physical access to the internal network and using a sniffer to collect usernames and user passwords or to record authentication sessions as they authenticate remotely • Replay attacks — Using the play back of a previously recorded authentication session in an attempt to gain unauthorized access • Compromised host — Gaining access to a remote laptop or workstation and using it to log into a network 14
Slide 50: Access Controls Indirect Access and Authentication Technologies While there are many technologies for providing indirect access and authentication, for the purposes of this chapter we will limit our discussion to: • • • • • • • • Single Sign-On (SSO) Terminal Server Controller Access Control System (TACACS) Extended Terminal Server Controller Access Control System (XTACACS) Terminal Server Controller Access Control System Plus (TACACS+) Remote Authentication Dial-In User Services (RADIUS) X.509 Kerberos Secure European System for Application in a Multi-Vendor Environment (SESAME) • Remote Terminal Solution — Secure Shell (SSH) Single Sign-On (SSO) SSO can best be defined as an authentication mechanism that allows a single identity to be shared across multiple applications. It allows the user to authenticate once and gain access to multiple resources. The primary purpose of SSO is for the convenience of the user. With that in perspective SSO can also help in mitigating some of inherent risks of access control subjects using a different password or authentication mechanism for each of the many systems they access in a large network. Simply put, the chances of a security breach naturally increase as the number of passwords and or authentication mechanisms increase. This must, of course, be balanced against the additional risk of using SSO in that once implemented a malicious hacker now only has to obtain a single set of authentication credentials and then has access to all of the systems that the respective access control subject was permitted to access. The following advantages and disadvantages of SSO must also be considered: Advantages of SSO • More efficient log-on process • Easier administration — When a new employee is hired, all of the accounts on all of the systems that the new employee needs to access can be quickly added from a single administration point. — When an existing employee is terminated, all access can be quickly and simultaneously restricted at a single administration point. — If an existing user loses his token or forgets his password, the administrator can quickly update the user’s authentication credentials from a single administration point. • Mitigates some security risks — Reduces the inherent risk of a user having to remember multiple passwords for multiple systems within the enterprise. 15
Slide 51: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® — Because only a single password is used, the user is more apt to use a much stronger password. — Timeout and attempt thresholds are enforced consistently across the entire enterprise. • SSO generally offers a good return on investment for the enterprise. The reduced administrative costs can often pay for the cost of implementing SSO in a short period of time. However, it should be noted that if scripting is used to facilitate the implementation of SSO, the typical reduced administration costs associated with SSO could be negated. Disadvantages of SSO • Difficult to implement across the enterprise — Many systems use proprietary authentication systems that will not work well with standard SSO systems. • Time consuming to implement properly — Many underestimate the amount of time necessary to properly implement SSO across all systems in the enterprise. • Expensive to implement — Because of the difficulty and time involved to properly implement SSO, it is expensive. A redundant authentication server is required to avoid a single point of failure. — Proprietary authentication systems may need expensive custom programming in order to be used in an SSO implementation and more often than not this cost is not considered in the original estimates and results in SSO implementation cost overruns. • Can increase security risks — Once SSO is implemented, a malicious hacker only has to compromise a user’s single authentication credentials and then has access to all of the systems that the user had rights to. This makes it essential to employ 2 factor authentication. — In some cases, the original authentication system for a difficult to implement system has to be weakened in an effort to get it to work reliably in an SSO system. Terminal Server Controller Access Control System (TACACS) TACACS is an older and once popular remote access authentication system and protocol that allows one or more remote access servers to send identification information to a TACACS authentication server for authentication and authorization. The implementation of TACACS provides indirect authentication technology that can be divided into three functional areas known as AAA (triple A): 1. Authentication 2. Authorization 3. Accounting 16
Slide 52: Access Controls Simplicity was one of the reasons TACACS was once so popular: 1. The user attempts to log in on the remote access server. 2. The remote access server forwards the user’s identification information to the TACACS authentication server. 3. After receiving the identification information from the remote access server, the authentication server either returns authorization information or it denies any access for the user. Simplicity was perhaps involved in a serious security issue that was built into TACACS by design. The communications between the remote access server and the authentication server is performed unencrypted — in clear text. Hence, it is a simple matter for a malicious hacker to see the user’s identification information as well as the returned authorization information thereby dramatically simplifying the potential compromise of the user’s account. Because it is a centralized access control architecture, it offers a single point of administration thereby reducing the effort and associated costs when compared to administering multiple separate authentication systems in decentralized architecture. Extended Terminal Server Controller Access Control System (XTACACS) A second version of TACACS, called XTACACS, provided extensions to the original TACACS protocol for the support of both SLIP/PPP and CHAP/ARAP authentication. Terminal Server Controller Access Control System Plus (TACACS+) TACACS+ is a later version of TACACS that, among other enhancements, is best known for solving the original TACACS communications security issues by encrypting the communications between the remote access server and the authentication server. Remote Authentication Dial-In User Services (RADIUS) RADIUS is popular Internet Engineering Task Force (IETF) implementation of an indirect authentication service. It is similar to TACACS in that it uses a remote access server to forward the access control subject’s information to an authentication server, the authentication server either returns the user’s associated rights or denies access. Another common feature is that RADIUS centralizes and reduces administrative work load. However, unlike TACACS and XTACACS, the RADIUS implementation of indirect authentication used encryption by design not as an afterthought. RADIUS in an IETF configuration offers a set of 255 standard attributes that are used to communicate AAA information between a client and a server. RADIUS in a Vendor Specific Attributes (VSA) implementation can extend the standard IETF attributes to an additional 255 VSA attributes. RADIUS is used by a number of network product vendors and is regarded as a de facto industry standard for indirect authentication. 17
Slide 53: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® X.509 X.509 is an International Telecommunications Union–Telecommunications Standardization Sector (ITU-T) recommendation originally issued in 1998 for indirect authentication services using public keys. X.509 is commonly used to secure authentication and communications for Secure Socket Layer (SSL) over the Hypertext Transfer Protocol (HTTP) basing its authentication on a digitally signed public key issued by a Certificate Authority (CA). The use of the digital certificate in authentication also affords X.509 the ability to provide nonrepudiation. X.509 allows an access control subject to establish multiple connections after properly authenticating only once, thereby offering SSO-like capabilities. Because X.509 is a recommendation and not necessarily a standard, there can be issues with its implementation across different vendors, i.e., a certificate created for a Netscape browser may not necessarily work for a Microsoft browser. Kerberos Kerberos, described in RFC 1510, was originally developed by the Massachusetts Institute of Technology (MIT) and has become a popular network authentication protocol for indirect authentication services. It is designed to provide strong authentication using secret-key cryptography. It is an operational implementation of key distribution technology and affords a key distribution center, authentication service and ticket granting service. Hosts, applications, and servers all have to be “Kerberized” to be able to communicate with the user and the ticket granting service. Like the previously discussed indirect authentication technologies, Kerberos is based on a centralized architecture, thereby reducing administrative effort in managing all authentications from a single server. Furthermore, the use of Kerberos provides support for: • Authentication — You are who you say you are. • Authorization — What can you do once you are properly authenticated. • Confidentiality — Keeps data secret. • Integrity — The data received is the same as the data that was sent. • Non-repudiation — Determines exactly who sent or received a message. The process in the use of Kerberos is substantially different from those indirect authentication technologies we have previously reviewed and is considerably more complex. The following is a simplified explanation of the Kerberos process that was adapted for use here from Applied Cryptography: Protocols, Algorithms, and Source Code in C by Bruce Schneier (Wiley 1993): 18
Slide 54: Access Controls 1. Before an access control subject can request a service from an access control object, it must first obtain a ticket to the particular target object, hence the access control subject first must request from the Kerberos Authentication Server (AS) a ticket to the Kerberos Ticket Granting Service TGS. This request takes the form of a message containing the user’s name and the name of the respective TGS. 2. The AS looks up the access control subject in its database and then generates a session key to be used between the access control subject and the TGS. Kerberos encrypts this session key using the access control subject’s secret key. Then it creates a Ticket Granting Ticket (TGT) for the access control subject to present to the TGS and encrypts the TGT using the TGS’s secret key. The AS sends both of these encrypted messages back to the access control subject. 3. The access control subject decrypts the first message and recovers the session key. Next, the access control subject creates an authenticator consisting of the access control subject’s name, address, and a time stamp, all encrypted with the session key that was generated by the AS. 4. The access control subject then sends a request to the TGS for a ticket to a particular target server. This request contains the name of the server, the TGT received from Kerberos (which is already encrypted with the TGS’s secret key), and the encrypted authenticator. 5. The TGS decrypts the TGT with its secret key and then uses the session key included in the TGT to decrypt the authenticator. It compares the information in the authenticator with the information in the ticket, the access control subject’s network address with the address the request was sent from, and the time stamp with the current time. If everything matches, it allows the request to proceed. 6. The TGS creates a new session key for the user and target server and incorporates this key into a valid ticket for the access control subject to present to the access control object-server. This ticket also contains the access control subject’s name, network address, a time stamp, and an expiration time for the ticket — all encrypted with the target server’s secret key — and the name of the server. The TGS also encrypts the new access control subject-target session key using the session key shared by the access control subject and the TGS. It sends both messages to the access control subject. 7. The access control subject decrypts the message and extracts the session key for use with the target access control object-server. The access control subject is now ready to authenticate himself or herself to the access control object-server. He or she creates a new authenticator encrypted with the access control subject-target session key that the TGS generated. To request access to the target access control object-server, the access control subject sends along the ticket received from Kerberos (which is already encrypted with the target 19
Slide 55: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® access control object-server’s secret key) and the encrypted authenticator. Because this authenticator contains plaintext encrypted with the session key, it proves that the sender knows the key. Just as important, encrypting the time of day prevents an eavesdropper who records both the ticket and the authenticator from replaying them later. 8. The target access control object-server decrypts and checks the ticket and the authenticator, also confirming the access control subject’s address and the time stamp. If everything checks out, the access control object-server now knows the access control subject is who he or she claims to be, and the two share an encryption key that they can use for secure communication. (Since only the access control subject and the access control object-server share this key, they can assume that a recent message encrypted in that key originated with the other party.) 9. For those applications that require mutual authentication, the server sends the access control subject a message consisting of the time stamp plus 1, encrypted with the session key. This serves as proof to the user that the access control object-server actually knew its secret key and was able to decrypt the ticket and the authenticator. In order to provide for the successful implementation and operation of Kerberos, the following should be considered: • Overall security depends on a careful implementation. • Trusted and synchronized clocks are required across the enterprise network. • Enforcing limited lifetimes for authentication based on time stamps reduces the threat of a malicious hacker gaining unauthorized access using fraudulent credentials. • The Key Distribution Server must be physically secured. • The Key Distribution Server must be isolated on the network and should not participate in any non-Kerberos network activity. • The Authentication Server can be a critical single point of failure. Kerberos is available in many commercial products and a free implementation of Kerberos is available from the Massachusetts Institute of Technology. Secure European System for Application in a Multi-Vendor Environment (SESAME) SESAME is similar to Kerberos and can be accessible through the Kerberos version 5 protocol. SESAME offers SSO with additional distributed access controls using symmetric and asymmetric cryptography (eases key management) to protect interchanged data. Promulgation, protection and the use of Privileged Attribute Certificates (PACs) are central features. The organization of a PAC is shown in Figure 1.5. 20
Slide 56: Access Controls Field Issuer domain Issuer identity Serial number Creation time Validity Time periods Algorithm ID Signature value Privileges Certificate information Miscellaneous Protection methods Description Name the security domain of the issuer Name the PAS in the issuer's domain A unique number for this PAC, generated by the PAS UTC time when this PAC was created Time interval when this PAC is valid Additional time periods outside which the PAC is invalid Identifier of the algorithm used to sign this PAC The signature placed on the PAC A list of (attribute, value)-pairs describing privileges Additional information to be used by the PVF Currently used for auditing purposes only Fields to control how the PAC is used Figure 1.5 The architecture of a SESAME implementation requires numerous components: • Client side components — User sponsor — Client application — APA client — Security manager • Domain security server — Authentication server — Privilege attribute server — Key distribution server — Security information management base • Server side components — PAC validation facility — Security manager — Server application The following is a simplified explanation of the SESAME process: 1. 2. 3. 4. 5. 6. The user contacts the authentication server. The user receives an authentication certificate. The certificate is delivered to a privilege attribute server. The user receives a privilege attribute certificate. The certificate is presented to the target that is to be accessed. An access control decision is made based on the certificate presented, as well as the access control list attached to the resource. Remote Terminal Solution — Secure Shell (SSH) SSH is an indirect authentication service (among other things) that was designed to replace earlier rlogin, telnet, and rsh protocols to provide secure encrypted communications between two un-trusted clients over an un-trusted network. It 21
Slide 57: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® was originally released in 1995 by Tatu Ylonen as free software with source code. Shortly thereafter, Tatu Ylonen formed the SSH Communications company in an effort to commercialize SSH and to provide a mechanism to support the growing number of SSH users worldwide. Typical SSH authentication methodologies that are supported: • Host-based trust files — /etc/hosts.equiv — rhosts • RSA-based user authentication — The user creates public/private keys using ssh-keygen. — The pubic key is placed in the user /.ssh/authorized_keys file. — When initiating connection, the username and chosen public key are sent to the remote host. Remote host sends a random sequence session key encrypted with the user’s public key. — The session key is decrypted with the user’s private key and is sent back to the remote host. — User is now authenticated. • rhosts along with RSA-based authentication — Uses RSA key exchange — Consults host-based trust file • Authentication using password — Since all traffic is encrypted, the password is not “in the clear.” • Kerberos • Tokens such as SecureID The typical encryption ciphers provided with the various SSH distributions may include: • • • • • • • • AES128 AES256 DES 3DES Blowfish Twofish ArcFour CAST The current vendors/implementations of SSH or SSH clients now include: • • • • • Lsh, the GNU Project’s implementation of SSH OpenSSH, an open source implementation of SSH. PuTTY SSH Tectia PenguiNet 22
Slide 58: Access Controls • • • • • • SSHDOS WinSCP JavaSSH Dropbear Idokorro Mobile SSH Corkscrew (enables a user to run SSH over HTTPS proxy servers) Several early vendor implementations of SSH (SSH-1) had numerous security vulnerability issues as reported by CERT/CC. A newer version has been released called SSH-2 that solves these issues and provides for several enhancements and/or improvements over SSH-1 including but not limited to: • Security enhancements — Diffie-Hellman key exchange — Message Authentication Code • Feature enhancements — Ability for multiple SSH shell sessions over a single SSH connection SSH-2 is endorsed and is in the process of being standardized by Internet Engineering Task Force (IETF). Access Control Concepts Access Control Formal Models There are three formal models for access control systems: 1. Bell–LaPadula 2. Biba 3. Clark–Wilson These models are theoretical in nature offering guidelines but no specific examples of their use. Further, they are not well suited for use within a dynamic enterprise environment that is constantly changing due to their inherent management overhead. Bell–LaPadula Formal Model The Bell–LaPadula formal model was written by David E. Bell and Len J. LaPadula in 1973 and is the basis for the confidentiality aspects of the mandatory access control model. In the simplest of terms, this model specifies that all access control objects be assigned a minimal security level and that access to the object is denied for any access control subject with a lower security level. We will discuss the aspects of the Bell–LaPadula formal model further and how it relates to mandatory access controls later in this chapter. Biba Formal Model The Biba formal model was written by K. J. Biba in 1977 and is the basis for the integrity aspects of the mandatory access control model. The Biba formal model provides for three primary rules: 23
Slide 59: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® 1. An access control subject cannot access an access control object that has a lower integrity level. 2. An access control subject cannot modify an access control object that has a higher integrity level. 3. An access control subject cannot request services from an access control object that has a higher integrity level. We will discus the aspects of the Biba formal model further and how it relates to mandatory access controls later in this chapter. Clark–Wilson Formal Model The Clark–Wilson formal model was written by Dr. David D. Clark and David R. Wilson in 1987, was updated in 1989 and, like the Biba formal model, it addresses integrity. However, unlike the Biba formal model, the Clark–Wilson formal model extends beyond limiting access to the access control object by adding integrity considerations to the processes that occur while using the access control object. The Clark–Wilson formal model effectively provides for the integrity of the access control object by controlling the process that can create or modify the access control object. The Clark–Wilson formal model also provides for the separation of duties. This aspect of the Clark–Wilson formal model establishes guidelines that require that no single person should perform a task from beginning to end and that the task should be accomplished by two or more people to mitigate the potential for fraud in one person performing the task alone. Access Control Evaluation Criteria — Orange Book The U.S. Department of Defense has published a series of books (the rainbow series), which have historically reigned as an authoritative reference for computer security. Some of the books are considered out dated as they primarily addressed only standalone computers and did not work well with current technology — client server computing. However, the first access controls systems implemented were based on these books, hence the relevance to this chapter. The books are divided up by subject matter and each one has a different color spine. The book that addresses access controls related to confidentiality has an orange spine and is most often referred to as the “Orange Book.” The official title is Department of Defense — Trusted Computer System Evaluation Criteria (TCSEC). While the subject matter for this chapter only references the Orange Book and Red Book, the listing of the complete series of books can be found in Figure 1.6. Online versions of the rainbow series of books can be found at: http://www.radium.ncsc.mil/tpep/library/rainbow. The complete historical reference of evaluated products can be found at http://www.radium.ncsc.mil/tpep/epl/historical.html. The Orange Book defines a set of guidelines that classify the security rating of a system as well as the respective level of trust. The security classifications provide for four classification levels A, B, C and D. Each level is 24
Slide 60: Access Controls Document 5200.28-STD CSC-STD-002-85 CSC-STD-003-85 Spline Color Orange Green Light Yellow Book Title DoD Trusted Computer System Evaluation Criteria, 26 December 1985 (Supercedes CSC-STD-001-83, dtd 15 Aug 83). DoD Password Management Guideline, 12 April 1985. Computer Security Requirements -- Guidance for Applying the DoD TCSEC in Specific Environments, 25 June 1985 (Light Yellow Book). Technical Rational Behind CSC-STD-003-85: Computer Security Requirements -Guidance for Applying the DoD TCSEC in Specific Environments, 25 June 1985. A Guide to Understanding Audit in Trusted Systems 1 June 1988, Version 2. Trusted Product Evaluations - A Guide for Vendors, 22 June 1990. A Guide to Understanding Discretionary Access Control in Trusted Systems, 30 September 1987. Glossary of Computer Security Terms, 21 October 1988. Trusted Network Interpretation of the TCSEC (TNI), 31 July 1987. A Guide to Understanding Configuration Management in Trusted Systems, 28 March 1988. A Guide to Understanding Design Documentation in Trusted Systems, 6 October 1988. A Guide to Understanding Trusted Distribution in Trusted Systems 15 December 1988. Computer Security Subsystem Interpretation of the TCSEC 16 September 1988. A Guide to Understanding Security Modeling in Trusted Systems, October 1992. Trusted Network Interpretation Environments Guideline - Guidance for Applying the TNI, 1 August 1990. RAMP Program Document, 1 March 1995, Version 2 Guidelines for Formal Verification Systems, 1 April 1989. A Guide to Understanding Trusted Facility Management, 18 October 1989 Guidelines for Writing Trusted Facility Manuals, October 1992. A Guide to Understanding Identification and Authentication in Trusted Systems, September 1991. A Guide to Understanding Object Reuse in Trusted Systems, July 1992. Trusted Product Evaluation Questionaire, 2 May 1992, Version 2. Trusted UNIX Working Group (TRUSIX) Rationale for Selecting Access Control List Features for the UNIX® System, 7 July 1989. Trusted Database Management System Interpretation of the TCSEC (TDI), April 1991. A Guide to Understanding Trusted Recovery in Trusted Systems, 30 December 1991. A Guide to Understanding Security Testing and Test Documentation in Trusted Systems. A Guide to Procurement of Trusted Systems: An Introduction to Procurement Initiators on Computer Security Requirements, December 1992. A Guide to Procurement of Trusted Systems: Language for RFP Specifications and Statements of Work - An Aid to Procurement Initiators, 30 June 1993. A Guide to Procurement of Trusted Systems: Computer Security Contract Data Requirements List and Data Item Description Tutorial, 28 February 1994. A Guide to Procurement of Trusted Systems: How to Evaluate a Bidder's Proposal Document - An Aid to Procurement Initiators and Contractors. A Guide to Understanding Data Remanence in Automated Information Systems, September 1991, Version 2. A Guide to Writing the Security Features User's Guide for Trusted Systems, September 1991. A Guide to Understanding Information System Security Officer Responsibilities for Automated Information Systems, May 1992. Assessing Controlled Access Protection, 25 May 1992. Introduction to Certification and Accreditation Concepts, January 1994. A Guide to Understanding Covert Channel Analysis of Trusted Systems, November 1993. CSC-STD-004-85 NCSC-TG-001 Ver. 2 NCSC-TG-002 NCSC-TG-003 NCSC-TG-004 NCSC-TG-005 NCSC-TG-006 NCSC-TG-007 NCSC-TG-008 NCSC-TG-009 NCSC-TG-010 NCSC-TG-011 NCSC-TG-013 Ver.2 NCSC-TG-014 NCSC-TG-015 NCSC-TG-016 NCSC-TG-017 NCSC-TG-018 NCSC-TG-019 Ver. 2 NCSC-TG-020-A NCSC-TG-021 NCSC-TG-022 NCSC-TG-023 NCSC-TG-024 Vol. 1/4 Yellow Tan Blue Neon Orange TeaGreen Red Amber Burgundy Dark Lavender Venice Blue Aqua Blue Red Pink Purple Brown Green Light Blue Light Blue Blue Silver Purple Yellow Bright Orange Purple NCSC-TG-024 Vol. 2/4 Purple NCSC-TG-024 Vol. 3/4 NCSC-TG-024 Vol. 4/4 NCSC-TG-025 Ver. 2 NCSC-TG-026 NCSC-TG-027 NCSC-TG-028 NCSC-TG-029 NCSC-TG-030 Purple Purple Forest Green Hot Peach Turquose Violet Blue Light Pink Figure 1.6 25
Slide 61: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Grade Level Definition Example Evaluated Products Boeing - MLS LAN, Gemini Gemini Trusted Network Processor Trusted IRIX, Harris (CyberGuard) CX/SX, Top Secret, ACF2, RACF Windows NT, DEC VMS, Novell NetWare, Trusted Solaris A B C A1 Verified Protection B1,B2,B3 Mandatory Access Controls C1, C2 D None Discretionary Access Controls This class is reserved for those systems that have been evaluated Fischer International - Watchdog but that fail to meet the PC Data Security, Okiok Data Ltd requirements for a higher RAC/M and RacMII evaluation class. Figure 1.7 further divided to varying levels using numeric designations as shown in Figure 1.7. Within the Orange book, access controls are addressed in levels B — Mandatory Access Controls and C — Discretionary Access Controls. Orange Book B Level — Mandatory Access Control Mandatory access control (MAC) is typically used in environments requiring high levels of security such as government or military systems. In mandatory access controls, the inherent problems of trying to rely upon each system owner to properly control access to each access control object is eliminated by having the system participate in applying a mandatory access policy (the system owner applies the “need-to-know” element). This policy affords three object classification levels; top secret, secret, and confidential. Each access control system subject (users and programs) are assigned clearance labels and access control system objects are assigned sensitivity labels. The system then automatically provides the correct access rights based upon comparing the object and subject labels. Mandatory access controls allow multiple security levels of both objects and subjects to be combined in one system securely. A common theme among applications of mandatory access control is the “No read up — No write down” policy applied to each subject’s sensitivity level. This is the “mandatory” part of mandatory access control. It is the implementation of the Bell–LaPadula security model: • The Bell–LaPadula Model addresses confidentiality — Simple Security Property — The subject cannot read information from an object with a higher sensitivity level than the subject’s. • Star Property — The subject cannot write information to an object with a sensitivity level that is lower than the subject’s. The Bell–LaPadula confidentiality model provides the mandatory access control system with the following mandatory access control parameters: 26
Slide 62: Access Controls • Top Secret level subjects — Can create as well as write only top secret level objects — Can read top secret level objects as well as lower sensitivity level objects —– secret and confidential — Cannot write “down” to lower sensitivity level objects — secret and confidential • Secret level subjects — Can create as well as write secret level objects and top secret level objects — Cannot read “up” in top secret level objects — Can read secret level objects as well as lower sensitivity level objects — confidential — Cannot write “down” to lower sensitivity level objects — confidential • Confidential level subjects — Can create as well as write confidential level objects as well as secret and top secret level objects — Can read only confidential level objects — Cannot read “up” in top secret or secret level objects The respective system owners have a limited amount of discretionary control in that they can restrict access to individual or groups of access control objects within the realm of their sensitivity level on a “need to know” basis. Orange Book C Level — Discretionary Access Control In discretionary access control (DAC), the owner of the access control object would determine the privileges (i.e., read, write, execute) of the access control subjects. This methodology relies upon the discretion of the owner of the access control object to determine the access control subject’s specific rights in order to afford the security of the access control object. Hence, security of the object is literally up to the discretion of the object owner. Discretionary access controls are not very scalable, rely upon the decisions made by each individual access control object owner, and it can be difficult to find the source of access control issues when problems occur. The primary difference between MAC and DAC other then the labeling associated with MAC is that MAC requires both the access control object owner and the system’s permission while DAC only requires the access control object owner’s permission. The implementation of discretionary access controls typically rely upon the use of access control lists (ACL) to determine the rights/permissions for access control subjects. In most implementations, every access control object has a default ACL defined upon creation. The object owners can modify the default ACL at their discretion to define a specific security policy. Simply put, the ACL defines “who” can do “what.” The “who” refers to what are commonly referred to as “host entry types” as shown in Figure 1.8. The 27
Slide 63: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Type user Permissions Apply To Access control subject, whose name is to be specified in the key field Group Access control subject, whose name is to be specified in the key field Host systems (target agents acting on behalf of Access control subject for install or copy) Access control subject with no matching user and group entries Access control subject not matching any other entry Access control subject-owner of the object Members of the group to which an Access control subject - object belongs group host other any_other object_owner object_group Figure 1.8 “what” refers to the typical rights and or permissions for respective access control subjects as shown in Figure 1.9. Discretionary access controls are common in most commercially available operating systems. Systems utilizing discretionary access controls Permission Definition Permits the access control subject to read the data contained within the access control object Read Permits the access control subject to write data to the access control object Write Permits the access control subject to create a new access control object Create Permits the access control subject to execute the code contained within the access control object Execute Permits the access control subject to Read, Write, Create and Execute the access control object Permits the access control subject to delete the access control object Delete Permits the access control subject to rename the access control object Rename Permits the access control subject to list the contents of an access control object when it is a directory List Explicetly denies the access control subject any No Access access to the access control object Permits the access control subject to change permissions, take ownership and grants all other access control permissions for the access control Full Control object Modify Figure 1.9 28
Slide 64: Access Controls can only qualify for Orange Book C level certification. Discretionary access controls are not eligible for A level or B level evaluation and certification. To overcome the issue of the Orange Book only addressing confidentiality and stand alone systems, the Red book, otherwise known as the Trusted Network Interpretation of the TCSEC (TNI) was introduced in 1987. The Red Book provides for the networking aspects that were absent in the Orange Book as well as addressing integrity and availability. In 2003 both the Orange Book and Red Book were superseded by the Common Criteria Evaluation and Validation Scheme (CCEVS). Further information on the CCEVS can be found at: http://niap.nist.gov/cc-scheme/index.html. Other Discretionary Access Control Considerations Authorization Table An authorization table is a matrix of access control objects, access control subjects and their respective rights as shown in Figure 1.10. The authorization table is used in some discretionary access control systems in order to provide for a simple and intuitive user interface for the definition of access control rules. While an authorization table provides for an increase in ease of use, it does not solve the inherent issue of discretionary access control in that you are still relying upon the access control object owner to properly define the access control rules. Further, the use of an authorization table does not decrease the instance of errors or violations that may occur when changes are made within the authorization table. Access Control Matrix An access control matrix is used in a discretionary access control system to provide for a simple user interface to implement an ACL. The access control matrix determines the access rights for access control objects to access control subjects as shown in Figure 1.11. Like the authorization table previously mentioned, the access control matrix does not decrease the instance of errors or violations that may occur when changes are made within the access control matrix. Time-Based ACL Rules The capabilities of ACL rules in some access control mechanisms have been extended to include temporal (time) Access Control Objects Access Control Procedure Procedure Subjects "A" "B" Bob Tom Mary Process "A" Process "B" Execute Execute Execute Read /Write Write File "A" Read File "B" Read/Write File "C" File "D" Read Read Read Write Read/Write Figure 1.10 29
Slide 65: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Access Control Objects Access Control Subject 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 X X XX X X XX XX XX XX X XXX X X XXX X XX XX X X X X X X XX X XX X Figure 1.11 considerations. The ACL rule can be configured to only be effective for a given time period. Non-Discretionary Access Control The following is a definition of nondiscretionary access control from the National Institute of Standards and Technology (NIST, May 19, 2006). “Most OSs provide what is called discretionary access control. This allows the owner of each file, not the system administrator, to control who can read, write, and execute that particular file. Another access control option is called non-discretionary access control. Non-discretionary access control differs from discretionary access control in that the definition of access rules are tightly controlled by a security administrator rather than by ordinary users.” Role-Based Access Control (RBAC) Role-based access control is generally considered to be discretionary because the owner determines which roles have access. RBAC is also discretionary because the owner determines the rules. While there are several different implementations of non-discretionary access controls, most implementations work on the principle of RBAC. RBAC works by assigning roles to access control subjects as well as labels to the access control objects that specify which roles are permitted access to the respective access control objects. Within an RBAC implementation, the ability to permit or deny the inheritance of roles within a given hierarchy is commonly available. RBAC in many respects is similar to a well- managed work environment. Each employee has an assigned role and job function; they are only permitted access to the information necessary to accomplish their job function. The inheritance aspects of RBAC can be thought of like the organization chart at a well managed company where-by roles can be inherited across employees at the same organizational level or downward in the organizational chart but perhaps not permitting inheritance of a role moving up the organizational chart to levels above the current assigned role. Rule Set-Based Access Control (RSBAC) A Linux specific open source initiative known as Rule Set-Based Access Control (RSBAC) has been in de30
Slide 66: Access Controls velopment since 1996 and in stable production since January 2000. RSBAC is based on the Abrams and LaPadula Generalized Framework for Access Control (GFAC). RSBAC works at the kernel level and affords flexible access control based on several modules: • • • • • • • • • • Mandatory Access Control module (MAC) Privacy module (PM) Function Control module (FC) File Flag module (FF) Malware Scan module (MS) Role Compatibility module (RC) Function Control module (FC) Security Information Modification module (SIM) Authentication module (Auth) Access Control List module (ACL) All security relevant system calls in the Linux kernel are extended by RSBAC security enforcement code. The RSBAC security enforcement code calls the central decision component, which then calls all active decision modules (see above listing) and generates a combined decision. This decision is then enforced by the RSBAC system call extensions. One of the original goals of RSBAC was to achieve Orange book B1 certification. Content Dependent Access Control Content dependent access control (CDAC) is most commonly used to protect databases containing sensitive information; hence CDAC can be thought of as mechanism for privacy enforcement. CDAC is commonly based on the Abrams and LaPadula Generalized Framework for Access Control (GFAC). CDAC works by permitting or perhaps denying the access control subjects access to access control objects based upon the explicit content within the access control object. A timely example is with CDAC in a medical records database application. A healthcare worker may have been granted access to blood test records; however, if that record contains information about an HIV test, the healthcare worker may be denied access to the existence of the HIV test including the results. Only specific hospital staff would have the necessary CDAC access control rights to view blood test records that contain any information about HIV tests. While high levels of privacy protection are attainable using CDAC, it comes at the cost of a great deal of labor in defining the respective permissions. Further, it should be noted that CDAC comes with a great deal of overhead in processing power as it must scan the complete record in order to determine if access can be granted to a given access control subject. This scan is done by an arbiter program to determine if access will be allowed. Context-Based Access Control Context-based access control (CBAC) is primarily used in firewall applications to extend the firewalls decision31
Slide 67: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® making process beyond basic ACL decisions to decisions based upon state as well as application-layer protocol session information: • A static packet filtering firewall is a good example of a firewall that does not use CBAC. It looks at each and every packet and compares the packet to an ACL rule base to determine if the packet is to be allowed or denied. • A stateful inspection firewall is a good example of a firewall that uses CBAC. The firewall also considers the “state of the connection,” i.e., if a packet arrives, that is part of a continuing session that had previously been permitted to pass through the firewall. As a result, subsequent packets that are part of that session are allowed to pass without the overhead associated with comparing the packet to the ACL rules. CBAC affords a significant performance enhancement to a firewall. CBAC is often confused with CDAC but they are two completely different methodologies. While CDAC makes decisions based upon the content within an access control object, CBAC is not concerned with the content it is only concerned with the context or the sequence of events leading to the access control object being allowed through the firewall. In the example of blood test records for CDAC above, the access control subject would be denied access to the access control object because it contained information about an HIV test. CBAC could be used to limit the total number of requests for access to any blood test records over a given period of time. Hence, a healthcare worker may be limited to accessing the blood test database more than 100 times in a 24-hour period. While CBAC does not require that permissions be configured for individual access control objects, it does require that rules be created in relation to the sequence of events that precede an access attempt. View-Based Access Control View-Based Access Control (VBAC) is also known as a type of Constrained User Interface and it is used in database applications to control access to specific parts of a database. VBAC restricts or limits an access control subject’s ability to view or perhaps act upon “components” of an access control object based upon the access control subjects assigned level of authority. Views are dynamically created by the system for each user authorized access. VBAC separates a given access control object into subcomponents and then permits or denies access for the access control subject to view or interact with specific subcomponents of the underlying access control object. VBAC example in a medical records database: • A billing clerk (access control subject) would be able to view the procedures, supplies, and related costs in a database (access control object) to be billed to a patient and would be restricted from seeing the result 32
Slide 68: Access Controls of any of the underlying tests and perhaps the doctors notes contained within the same database (access control object). • A nurse (access control subject) would be able to view the results of procedures and tests as well as the doctor’s notes but would be restricted from seeing the costs for the procedures and supplies. VBAC example in a firewall administrator’s management console: • A firewall user administrator (access control subject) would be able to add new users and reset user passwords in the firewalls database (access control object) but would be restricted from seeing alerts or altering the firewall ACL rules within the same database. • A firewall monitor (access control subject) would be able to see alerts in the firewall database (access control object) but would not be able to see or alter any information in the database relating to users or ACL rules. • A firewall VPN administrator (access control subject) would have the ability to enter VPN related rules into the firewall database (access control object) to facilitate creating a point to point VPN tunnel or perhaps to permit a client to server VPN connection. However, the users would have to already exist in the firewall database (access control object) and the VPN administrator (access control subject) would be restricted from seeing alerts and access control rules that did not specifically relate to the VPN operations within the database. • A firewall security officer (access control subject) would have full access to all information within the firewall database (access control object). While the view that is given to an access control subject may only be a partial view of the information available from the access control object, it is important in the proper application of VBAC that the views presented to the access control subject appear normal complete and in context - without revealing signs of any missing information. Temporal Isolation (Time-Based) Access Control Temporal Isolation (Time-Based) Access Control is commonly used to enhance or extend the capabilities of (Role-Based Access Control) RBAC implementations. This combined methodology is often referred to as Temporal Role-Based Access Control (TRBAC). Effectively, TRBAC applies a time limitation to “when” a given role can be activated for a given access control subject. • A high level “top secret” role would be assigned to a given access control subject during the normal 8:00 a.m. to 5:00 p.m. working hours. • A lower level “confidential” role would be assigned to the same access control subject during the 5:00 p.m. to 8:00 a.m. nonworking hours. To decrease the labor of assigning TRBAC rules to each of many individual access control subjects, most implementations of TRBAC assign the temporal based classification levels to the perhaps lower number of access control objects rather than to the access control subject. Hence, a given 33
Slide 69: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® access control object would have a temporal based classification level that is effective against all access control subjects. Temporal extensions are also used to enhance other access control methodologies. It is common today to find access control devices that support timebased access control rules. The temporal enhancement of the access control rule only allows the rule to be effective during the specified time period. Other Access Control Considerations Capability Tables A capability table provides the definition of the access control rights for a given access control subject to a given access control object within an access control system. The capability tables also include the authorization rights of the access control subject such as read, write, execute, delete, and so forth, thereby detailing the explicit access control subject’s privileges. The access control right from the capability table for the respective access control object is referred to as a “ticket.” This ticket can grant the access control subject access to the specified access control object for a given period. Access to a protected access control object is only granted if the access control subject possesses a capability ticket for the access control subject. In closing our discussion of access control methodologies, it is important to note that there are several other methodologies to control access to and from both access control objects and access control subjects. These methodologies range from individual or combined criteria that can be enforced across tables, roles, time, and other constraints that are either at the data owner’s discretion or defined within the system in a mandatory manner without the discretion of the access control subject. Operating System Hardening One of the most misunderstood terms in network security today is OS (operating system) hardening or hardened OS. Many vendors claim their products are provided with a “hardened OS.” What you will find in virtually all cases is that the vendor simply turned off or removed unnecessary services and patched the operating system for known vulnerabilities. Clearly, this is not a “hardened OS” but really a “patched OS.” A “real” hardened OS is one in which the vendor has modified the kernel source code to provide for a mechanism that clearly supplies a security perimeter between the nonsecure application software, the secure application software, and the network stack. One common method of establishing a security perimeter is to write a label embedded within each packet as it enters the server. The label determines specifically what permissions the packet has and which applications can act upon the packet. If the packet’s label does not afford the necessary permissions, then the packet is dropped 34
Slide 70: Access Controls Security Attack Security Attack Network Attack Non-Secure Application Software Secured Application Software Firewall Secure Operating System Secure Network System Computer Hardware Figure 1.12 as shown in Figure 1.12. While this methodology provides tight control over which packets can be acted upon by both secure and nonsecure applications, it also affords a security perimeter in that external packets can be rejected if they attempt to act upon the secure operating system kernel, secure network, and underlying hardware. This reduces the risk of the exploitation of a service running on the hardened OS that could otherwise provide root level privilege to the hacker. The security perimeter is typically established using one of two popular methodologies: Multi-Level Security and Compartmentalization. MLS establishes a perimeter using labels assigned to each packet and applies rules for the acceptance of said packets at various levels of the OS and services.Not to be confused with a mere CHROOT Jail , compartmentalization goes well beyond that of just a traditional sandbox approach — strong CHROOT Jail, whereby an application runs in a dedicated kernel space with no path to another object within the kernel. Compartmentalization includes a full MAC implementation and several other kernel level hardening features: • • • • Network stack separation Triggers for intrusion detection Control of “super user” privileges Principle of least privilege What is a “patched” OS? A patched OS is typically a commercial OS from which the administrator turns off or removes all unnecessary services and installs the latest security patches from the OS vendor. A patched OS has had no modifications made to the kernel source code to enhance security. 35
Slide 71: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Is a patched OS as secure as a hardened OS? No. A patched OS is only secure until the next vulnerability in the underlying OS or allowed services is discovered. An administrator may argue that, when he has completed installing his patches and turning off services, his OS is secure. The bottomline question is: With more than 70 new vulnerabilities being posted to Bug Traq each week, how long will it remain secure? How do you determine if a product is provided with a hardened OS? If the product was supplied with a commercial OS, you can rest assured that it is not a hardened OS. The principal element here is that, in order to harden an OS, you must own the source code to the OS so that you can make the necessary kernel modification to harden the OS. If you really want to be sure, ask the vendor to provide third-party validation that the OS is, in fact, hardened at the kernel level (see http://www.radium.ncsc.mil/tpep/epl/historical.html). Why is OS hardening such an important issue? Too many in the security industry have been lulled into a false sense of security. Decisions on security products are based primarily on popularity and price with little regard to the actual security the product can provide. With firewalls moving further up the OSI model, more firewall vendors are providing application proxies that operate in kernel space. These proxies, if written insecurely, could provide a hacker with root access on the firewall itself. This is not a “What if?” proposition; it just recently happened with a popular firewall product. A flaw in their HTTP security mechanism potentially allows a hacker to gain root access to the firewall, which runs on a commercial “patched” OS. Where can you find additional information about OS vulnerabilities? • • • • • http://www.securiteam.com http://www.xforce.iss.net http://www.rootshell.com http://www.packetstorm.securify.com http://www.insecure.org/sploits.html Where can I find additional information about patching an OS? • More than 40 experts in the SANS community worked together over a full year to create two elegant and effective scripts: — For Solaris: http://yassp.parc.xerox.com/ — For Red Hat Linux: http://www.sans.org/newlook/projects/bastille_ linux.htm • Lance Spitzner has written a number of great technical documents (http://www.enteract.com/~lspitz/pubs.html): — Armoring Linux — Armoring Solaris — Armoring NT 36
Slide 72: Access Controls • Stanford University has also released a number of excellent technical documents (http://www.stanford.edu/group/itss-ccs/security/Bestuse/ Systems/): — Red Hat Linux — Solaris — SunOS — AIX 4.x — HPUX — NT Patch Management With over 70 new vulnerabilities being reported in operating systems and applications each week, it is not difficult to understand the importance of patch management. Even in a relatively small organization, patch management can be a full-time effort. For large enterprises that span multiple locations and with the added complexity of remote users, patch management can be a daunting task. Patch management is not as simple as scanning servers and desktops and deploying the necessary patches. History has shown us that vendor patches often break applications and in some cases either reintroduce legacy vulnerabilities or introduce new vulnerabilities. Hence, patches should always be first tested in a lab environment to address security and stability concerns and be approved by an administrator before mass deployment across the enterprise. Several vendors now offer comprehensive automatic patch management solutions. Key components of current technology offerings afford the following capabilities: • Support for applications across multiple operating systems • Both ad hoc and automatic recurring scheduled scanning of computers individually or in user definable groups — Facilitates staged scanning to minimize bandwidth impact • WAN wide scan for installed patches and missing patches — including that date and time that a respective patch was deployed • Provides for any required patch file configuration options and reboot notifications and actions • Provides for administrator configurable patch file locations • Allows the administrator to approve or deny selected patches — If a patch is currently being analyzed within the organizations lab environment, the patch management system can scan for and identify all computers that may be subject to a potential vulnerability. This can be useful in determining if any security policy changes are necessary to protect the organization pending patch approval and deployment. 37
Slide 73: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • Deploy patches in ad hoc mode or in administrator configured groups. — Supports staged deployment to minimize bandwidth impact Vulnerability Management Vulnerability management has become a necessity in today’s Internet environment where vendors unfortunately often claim that hackers are lazy and wait for the vendor to release a patch for a vendor-discovered vulnerability and then reverse engineer the patch to create an exploit. All too often we find that it was, in fact, actually a hacker that found the vulnerability and had actually created the exploit and circulated it across the Internet long before the vendor knew of any problem at all. The Windows Metafile (WMF) vulnerability is but one of many examples of this problem. Code for the actual WMF exploit was being sold by the Blackhat community on the Internet months before Microsoft even acknowledged that the vulnerability existed. A third party created a patch and it was endorsed by several industry experts as necessary to deploy immediately, while Microsoft was still considering if the exploit warranted a patch at all. Vulnerability management is similar to patch management in that with current technology offerings it can automatically scan and compile a WAN wide database of all applications and the current revision and patch levels. Vulnerability management differs from patch management in that it utilizes third party — vendor neutral data sources in an effort to be fully aware of current vulnerabilities. Another issue comes into play when multiple vulnerability research organizations separately perform analysis on the same vulnerability and use a different naming convention when reporting the vulnerability publicly. Those organizations that perform vulnerability research now typically adhere to the Common Vulnerability and Exposures (CVE) dictionary. The CVE dictionary is a resource to standardize the naming conventions of known vulnerabilities and security exposures. CVE provides a listing of CVE compliant services and products at http://www.cve.mitre.org/compatible/product.html. Armed with the knowledge in the database of current assets, their respective version numbers and patch levels on each and every one of the computers across the enterprise and the real-time vulnerability subscriber data, the administrator is better able to manage risk. Simply put, vulnerability management systems provide the information necessary to allow the administrator to make timely/informed decisions regarding changes to security posture in response to known threats. Because of their many similarities, it could be safely assumed that there will eventually be a convergence of patch management and vulnerability management in a single product offering. 38
Slide 74: Access Controls Sample Questions 1. What are the three principle components of access control systems? a. Access control objects b. Biometrics c. Access control subjects d. Access control systems Which of the following are behavioral traits in a biometric device? a. Voice Pattern b. Signature Dynamics c. Keystroke Dynamics d. All of the above In the measurement of biometric accuracy which of the following is commonly referred to as a “type two error”? a. Rate of false acceptance — False Acceptance Rate (FAR) b. Rate of false rejection — False Rejection Rate (FRR) c. Cross over error rate (CER) d. All of the above The three functional areas of TACACS known as AAA (triple A) are? a. Authentication b. Authorization c. Availability d. Accounting 2. 3. 4. 5. Which of the following is an International Telecommunications Union — Telecommunications Standardization Sector (ITU-T) recommendation originally issued in 1998 for indirect authentication services using public keys? a. Radius b. X.509 c. Kerberos d. SESAME 6. Which of the following is NOT one of the three primary rules in a Biba formal model? a. An access control subject cannot access an access control object that has a higher integrity level. b. An access control subject cannot access an access control object that has a lower integrity level. c. An access control subject cannot modify an access control object that has a higher integrity level. d. An access control subject cannot request services from an access control object that has a higher integrity level. 39
Slide 75: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® 7. Which of the following is an example of a firewall that does not use Context Based Access Control? a. Application Proxy b. Static Packet Filter c. Stateful Inspection d. Circuit Gateway In consideration of the three basic types of authentication which of the following is incorrect: a. Knowledge based = Password b. Token based = Smartcard c. Characteristic based = Biometric d. None of the above In the authorization provided to the access control subject by an access control system, which of the following is not a consideration for an Access Control Subject? a. Temporal — Time of day, day of request b. Password or token utilized c. False Rejection Rate d. Locale from where the access control subject authenticated Password selection is typically based on which of the following criteria? a. Minimum password length b. Authorizations, rights, and permissions c. Required usage of letters, case, numbers, and symbols in the makeup of the password d. All of the above Which of the following should be considered in the routine monitoring of an access control system? a. The regular monitoring of changes to accounts can help to mitigate the risk of misuse or unauthorized access. b. All changes to accounts within the access control system should be logged and reviewed on a regular basis. c. Particular attention should focus on any newly created accounts as well as any escalation of the privileges for an existing account to make certain that the new account or the increased privileges are authorized. d. All of the above Which of the following is not true in the consideration of object groups? a. It is a common practice to assign the appropriate permissions to a directory, and each object within the directory inherits the respective parent directory permissions. 8. 9. 10. 11. 12. 40
Slide 76: Access Controls b. Although configuring individual objects affords maximum control, this granularity can quickly become a administration burden. c. By incorporating multiple objects with similar permissions or restrictions within a group or directory, the granularity is thereby coarsened and the administration of the access control system is simplified. d. Configuring individual objects affords maximum control, this granularity can reduce administration burden. 13. In the three basic types of authentication, which of the following are related to “something you have”? a. Synchronous or asynchronous token b. Biometric c. Smartcard d. All of the above Which of the following is an asynchronous device? a. Time-based token b. Event-based token c. All of the above Which of the following are characteristics in biometric behavioralkeystroke dynamics? a. The length of time each key is held down b. Tendencies to switch between a numeric keypad and keyboard numbers c. Acceleration, rhythm, pressure, and flow d. All of the above 14. 15. 41
Slide 78: Domain 2 Security Operations and Administration Bonnie Goins, CISSP A key area for the security practitioner in which to develop strong skills is the area of security administration. This chapter discusses the aspects of the secure administration of an enterprise. It provides definitions for common security terms the practitioner will use in day-today work; discusses information critical to the understanding of information security fundamentals; and covers the personnel and technical aspects of securing an environment. What Is “Security Administration”? As defined in (ISC)2’s® SSCP® Review Seminar, “security administration encompasses the concept of identification, authentication and accountability of an enterprise’s information assets.” It includes the development of policies, procedures, guidelines and standards, as well as mechanisms for traceability in the event of disaster. Fundamentals of Information Security The A-I-C Triad Central to the concept of security is the A-I-C triad. Some practitioners have also heard it referred to as the C-I-A. These three tenets are Availability, Integrity, and Confidentiality. Availability Availability is the assurance that resources can be successfully accessed by authorized users when they are needed and in the form needed. Availability may be provided for an organization through: appropriate business continuity, incident response and disaster recovery planning; redundant 43
Slide 79: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® network architecture; redundant power generation and surge protection; data storage (both electronic and paper data storage) and the ability to access online data through more than one data path; and other mechanisms designed to overcome denial of service to authorized users. Denial of service can be precipitated in a completely innocent fashion (i.e., hardware is made “unavailable” due to a malfunction of components; personnel inadvertently cause an outage) or can occur through malfeasance. An example of this type of denial of service would include a deliberate attack of a network or its resources by an internal or external attacker. The attacker floods the network resources in question with bogus requests, until the bandwidth is saturated and the network can no longer respond to users at all. Integrity Integrity is the assurance that data stored, processed and transmitted has not been modified or destroyed in an inappropriate manner, either inadvertently or maliciously, from its original and correct state. That is, only authorized users are able to modify data, and then through appropriate means. Verification of both paper and electronic data must be performed by systems and personnel in order to determine that there are no data integrity issues. Fortunately, there are safeguards that can be taken to assist an organization with the provision of data integrity; these include appropriate control of the physical environment within the organization. No unauthorized individuals should ever be granted access to critical systems. In the case of physical control, only network administrators, system administrators, or privileged (authorized) users should be granted access to the systems and the data that resides on, is processed or is transmitted by them. It is essential that an organization maintains a current accounting of privileges provided to users to ensure that authorization continues to be appropriate. This can be done by verifying a user’s role in the organization, the minimal set of data that is required for successful completion of tasks for this role (this is the concept of “least privilege”) and the data’s location (i.e., system location). Monitoring and Maintenance of Appropriate Environmental Controls over Data and Systems This activity would include monitoring of humidity, temperature, pollutants, and other environmental concerns, as they relate to the protection of critical systems and data. Some organizations also monitor air quality for biological and other hazardous contaminants, in accordance with emergency management concepts that have been presented by federal and state governmental agencies. Policies and Procedures An important part of maintaining data integrity in an organization is to create, implement, maintain, monitor, and enforce 44
Slide 80: Security Operations and Administration appropriate organizational and information security policies and procedures that set expectations for the personnel within the organization, as well as its business partners, contractors and vendors. Given that issues with data integrity may revolve around appropriate data input and validation of data pre- and post-processing, communicating to authorized users expected practices that may assist to safeguard data is crucial. Business continuity and incident response plans also assist in the protection of the integrity of data within the organization. Data can be modified or lost during a calamity or an intrusion; therefore, having formally documented practices available to be used during these highly charged times is critical to performance during the emergency or intrusion. Infrastructure Public Key Infrastructure (PKI) also assists an organization in protecting its data integrity. It does so through the use of digital signatures. These electronic signatures are used for a number of purposes, including the signing of developed computer code, the protection of e-mail, and for the signing of electronic documents. Confidentiality Confidentiality may be defined as limiting access to protected data or systems to only those personnel, business partners, contractors, or vendors who are authorized (or have “need-to-know,” in a properly secured environment). Like integrity, confidentiality refers to data and systems. Confidentiality is often confused with “privacy,” which is an individual’s right regarding hihe or sher data. Confidentiality’s main tenet is authorization; that is, restriction of resources to authorized personnel or systems. Confidentiality is also a primary tenet in regulatory compliance. In HIPAA, Sarbanes-Oxley, GLBA, NERC/FERC, FISMA, and other regulations, confidentiality must be maintained in order to meet compliance objectives. This puts an additional burden on administrators of systems on which critical data resides. It also puts additional burden on authorized users in an organization to meet expectations surrounding acceptable system use and appropriate data handling. What are the consequences in the event of a breach of confidentiality? Clearly, as stated above, inappropriate disclosure of confidential information can result in a breach of compliance with regulatory objectives. This can mean fines, lawsuits and litigation by those compromised (to include individuals, organizations, and others, potentially including government entities, depending upon the type of information collected), which might also bring with it a jail term, as can be evidenced by recent litigation against corporate malfeasance. There can also be intangible effects that directly affect the bottom line of an organization, such as loss of prestige or public support, perhaps resulting in a decrease in an organization’s net worth through reduction in its stock price. 45
Slide 81: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Confidentiality can be promoted through correct identification of each authorized user, proper access control mechanisms for sensitive data that is stored on an organization’s systems, and the use of appropriate encryption techniques for sensitive data that is in transmission. Compliance with Policy Infrastructure Building a policy infrastructure within an organization is useless unless there is a solid and effective effort to enforce that infrastructure. Enforcement ensures that the organization and its staff meet, or are “in compliance with,” the expectations as set forth in the policy deliverables that make up the policy infrastructure. Determination of compliance is aided through both technological and human means. Examples of activities designed to measure and promote compliance are presented below. Security Event Logs Monitoring of security in an automated fashion is common among most organizations. Security automation, such as intrusion detection/prevention systems, generate system logs (syslogs). These logs can be reviewed by security administrators to observe where deviations from stated policy occur. Examples of deviation from stated policy can include inappropriate use (such as surfing prohibited Web sites) and unauthorized access (such as using another’s credentials to obtain increased access). A good method for reviewing event logs is to aggregate and run them from a single syslog server. An advantage is that data can be viewed as a pool rather than through separate efforts. A disadvantage is that aggregated syslogs must be tuned so that the data is not overwhelming to the security administrator. Significant expertise is required to properly tune the logs so that important information for review is not lost or overlooked during log review. It is important to note that logs should be reviewed daily for anomalies. If logs are only reviewed sporadically, it may be impossible to determine when, and under what conditions, security expectations have been violated within the organization. Upon completion of the log reviews, the security administrator must formally “sign off” and retain the signature for future auditing purposes. Logs should be saved in a secured location, such as an offsite storage facility or a secured warehouse. Archive requirements vary by legislation, but can span from three to six years or more. Logs that are not bound by legislation should be archived as long as business reasons dictate. An average archive length approximates three years. 46
Slide 82: Security Operations and Administration Information Security Compliance Liaison Many business units require some assistance in interpreting, implementing, and monitoring security compliance. It is useful to assign a compliance coach (liaison) to business units to facilitate the incorporation of security into daily operation. Coaches may be assigned either from the information security discipline or from the business unit, but must be dedicated, so as to promote continuity. Coaches must receive periodic training in both security and compliance issues that face the organization. Coaches assigned from the information security area must also receive training in the department’s operations. Remediation When issues are discovered, it is important for the organization to determine whether the root cause must be fixed, or remediated. Remediation must be undertaken relative to risk; that is, high-risk issues must be addressed prior to lower-risk issues. Remediation ranges from the human to the technical, and can include everything from hardware or software implementation to security awareness education. In a compliance-driven environment, threats to compliance are always considered high risk. Security Administration: Data Classification Data classification is a necessary security activity within organizations looking to protect their assets. Classifying data by its level of sensitivity allows an organization to communicate expectations regarding how that data is labeled and handled by authorized users. Data classification often commences after an organization has accounted for all its assets, perhaps documenting them in an asset inventory. This asset inventory may be the output of the organization’s Business Impact Analysis (BIA) and is also used as an input to the risk assessment process. Data classification typically begins by creating a “data classification scheme,” or a framework for communicating labeling and handling instructions to employees, contractors, business associates, vendors or other authorized personnel. Examples of a data classification scheme can include: • Restricted — this label is reserved exclusively for the organization’s most sensitive data. An example would be compliance-oriented data, such as electronic personally identifiable healthcare information (ePHI). • Confidential — this label is reserved for data that has a very limited distribution among authorized personnel, limited to only those with need-to-know. An example would be intellectual property that has a group distribution. 47
Slide 83: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • Internal Use Only — this label is reserved for data that can be disseminated throughout the organization. An example would be the corporate information security policy. • Public — this label is reserved for data that can be freely distributed both internal and external to the organization. An example would be information contained within the nonrestricted part of an organization’s Web site. The United States Department of Defense, along with other government and military organizations, implements a data classification scheme that includes the following categories: • • • • • Top Secret Secret Confidential Sensitive but Unclassified Unclassified In order for data to be classified, it requires an “owner.” A data owner reviews the data to determine whether it is sensitive. A data owner may also determine whether the data is critical to the organization’s functions, although criticality is typically determined by senior executives, who may or may not be data owners, but are responsible for the organization’s continuing operations. A data owner also determines permission levels and facilitates access control by identifying those individuals or groups with need-to-know and by assigning them to the appropriate permission levels. The data owner is also responsible for periodically reviewing access and updating that access, along with permissions, as required. Data “custodians” must also be considered in the data classification scheme. Custodians handle and protect data, but do not “own” it. A good example of a data custodian is an Information Systems department within an organization. Network administrators protect the data as it is stored and transmitted; system administrators protect the data while it is being processed. Another good example of a data custodian could be an end user that has a need to work with the data to fulfill a job function, such as a Compliance Officer at a hospital (provider). Given the number of individuals or groups that may be owners or custodians of data, it is clear that expectation must be communicated for the data is to be handled in a consistent and secure manner. Creation, implementation, maintenance, monitoring, and enforcement of appropriate data classification, labeling and handling policies, procedures and standards facilitates this goal. 48
Slide 84: Security Operations and Administration The formal documentation listed above should also incorporate the following aspects as part of the classification: • Exclusive possession — this encompasses intellectual property held by the organization • Utility — this aspect discusses how the classification, and the formal documentation surrounding classification, will be used within the organization • Cost of creation/recreation — this aspect discusses creation and replacement cost, as it relates to both data, documentation, backup and BCP • Liability — this aspect discusses the organization’s liability with regard to its critical and sensitive data, as well as its proper labeling and handling • Operational Impact — this aspect discusses the impact that proper classification, labeling and handling of the data has on the organization • Sanitation and media disposal — Instructions relative to appropriately scrubbing media (or shredding paper media) must also be included as part of the data classification effort Marking and Labeling Once the data classification scheme has been developed and approved by management, it is time for the organization to begin the job of marking and labeling data assets. Data in all its forms must be marked, including any magnetic and optical media, such as data tapes, audio and videotapes, diskettes, CDs, DVDs, and so on, as well as all paper documents. It is not sufficient to simply mark the first page of a document; the cover and all pages must be marked with the proper classification, in the event the document is disassembled. Where possible, data should also be labeled for access control permissions. This can be seen in software, with the labeling of field level, file level and directory level access permissions. Labels What do data labels look like? If magnetic media is being labeled, a standard label may be applied to the permanent tape housing. The classification must be visible to any authorized user who would handle the media. An internal system readable label is applied to the first section of the tape or magnetic media. In the case of paper documents, a stamp or watermark with the proper classification is acceptable. It is highly advisable that the organization create appropriate documentation templates with the classification automatically generated either in the header, the footer, or as a watermark across the page. 49
Slide 85: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Assurance and Enforcement It is crucial for the organization to continually monitor compliance with the classification scheme. This monitoring creates awareness to support successful control and handling of information. Should there be a lapse, the organization could potentially be jeopardized through loss or exposure of sensitive data. Below are some methods that could be utilized to assure the organization that there is compliance with the data classification policies, procedures, and standards: • Walking through the organization and spot checking for data left in open view, such as on desks, printers, faxes, in mailboxes, and so on can expose lapses in properly securing sensitive information. • Undertaking a review of the organization’s data dictionary, if one exists, as well as a review of metadata, reporting formats, and the asset inventory itself can assist. • Spot-checking for proper disposal of all types of media may assure the organization that proper disposal is occurring. Make sure to check hard drives in computer and multifunction machines, such as printers and copiers, as well, to ensure that they are properly scrubbed prior to disposal or reallocation. • Periodically conducting access control authorizations reviews, in a formal way, by data owners. Identity Management Identification is the process of claiming an individual’s, group, or system’s identity. Authentication is the process of verifying identity claims. The discipline of “identity management” is central to an organization’s access control objectives. It includes: identification of each of the individual components of the organization or “system” (such as a user, network, departments, and so on); the identification of users within the organization or system; identification of appropriate access rights (typically based on role; see the concept of “least privilege”); and using these identifications to limit access to the organization’s resources based on the rights and restrictions that are “identified” as belonging to that component or system. A good example of identity management is the use of an ID badge that allows access to an organization’s data center. Not everyone in an organization can enter the data center; only those authorized or have the access rights associated with their roles, are typically allowed in. Access control in a computer network typically centers on credentials, such as user IDs and passwords. Should a user forget a credential, there is a mechanism that can be employed to reset the password; this mechanism can be performed manually or in an automated fashion. Software used for 50
Slide 86: Security Operations and Administration identity management may save an organization time and money if it is used to allow users to reset their own passwords. Alternatively, perhaps an organization wishes to synchronize user passwords across both applications and systems. This is a part of the concept of “single sign-on,” or one login attempt that, when successful, grants access to the user across all authorized applications and systems. Security Administration: Configuration Management What Is Configuration Management (CM)? As stated in the Trusted Computer Systems Evaluation Criteria (TCSEC), a configuration management system maintains control of a system throughout its life cycle, ensuring that the system in operation is the correct system, implementing the correct security policy. The Assurance Control Objective as it relates to configuration management leads to the following control objective that may be applied to configuration management: “Computer systems that process and store sensitive or classified information depend on the hardware and software to protect that information. It follows that the hardware and software themselves must be protected against unauthorized changes that could cause protection mechanisms to malfunction or be bypassed completely. Only in this way can confidence be provided that the hardware and software interpretation of the security policy is maintained accurately and without distortion.” Why Is CM Important? Given that one of the primary tenets of configuration management is to keep assets free from unauthorized modification, it is clear that configuration management may assist an organization through its contribution to baseline data surrounding the asset, which may in turn assist the organization in recovery of the asset post-incident. As stated in the SSCP Administrative Domain course, configuration management consists of four separate tasks: • • • • Identification Control Status Accounting Auditing When a change is initiated in an automated system, its business requirements and design input to the new system must be formally identified and documented. Additionally, the change, as well as the asset resulting from the change, must be approved by an appropriate third party, typically a Change Control Board. Once the approval is obtained, the change is implemented. 51
Slide 87: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® The process must be documented and progress reported to senior management. Post-implementation, appropriate testing for both functionality and quality must be undertaken. Once testing is completed, a configuration audit must be undertaken and compared with the security policy(ies) relevant to that system. Change Control Roles in CM The practice of configuration management is multidisciplinary. The participants, along with their responsibilities, are listed below. • Senior Management — Responsible for approval for CM projects and staffing — Responsible for oversight of the CM plan to ensure it meets business objectives — Responsible for status reviews and approval of CM project or plan changes • Configuration Management Unit — Responsible for identification or approval of the asset characteristics affected by CM — Responsible for assigning CM asset characteristics to a custodian — Responsible for creation and update (as appropriate) of CM baselines — Responsible for implementation of the authorized changes to the configurations — Responsible for status reporting to senior management — Responsible for the implementation of the CM • Change Control Board — Responsible for review, approval and oversight of change requests to CM projects — Responsible for review of CM for determination that the final product functions as advertised • Quality Assurance — Responsible for oversight relative to the conformance to the organization’s policies, procedures and standards, as well as for conformance to the CM project plan — Responsible for ensuring that deliverables produced during the CM meet customer requirements, quality requirements and all organizational standards for delivery Baselines Baselines are measurements of the current state, or a “point in time,” for use as a benchmark as an asset, such as a system, an application, or a policy, evolves. Functional baselines are measures to ensure that the asset adheres 52
Slide 88: Security Operations and Administration to design requirements. Once the functional baseline is set, any changes to that asset must be authorized and formally documented. Product baselines reflect the finalized state of the asset to be used for testing. At this point a “product” has been developed and is ready for implementation. Baseline Measurements There are many aspects by which a baseline can be measured, some of which are business- and not technology-oriented. The following metrics represent some of the measurements which one might expect to be included in an appropriate baseline state: • Network utilization • Server utilization • The extent to which proper security contributes to the organization ensuring it retains its assets • IDS measurements that indicate security function is appropriately implemented and is operating efficiently Change Management Process The following are elements within the process of change management: • Establish baseline • Create formal, documented procedures for facilitating changes to systems • Implement any changes required and approved in a formal and controlled fashion • Formally update the current baseline • Monitor the current baseline for any unexpected events, incidents or issues Change Control Board The Change Control Board (CCB) is a multidisciplinary steering committee within an organization, assigned the task of oversight of CM. The members of the CCB meet regularly (in person, by conference, or video call) to discuss all relevant CM topics that might occur within an organization. These might include requested changes, status reporting, issues, and quality control. The board also ensures that only approved changes are implemented into the asset, after formally reviewing, as well as documenting the review, of all requested changes. CCB Charter The CCB constructs its charter, or the rules it operates by within the organization. A typical charter consists of, at least, the following elements: • Responsibilities of the CCB • Purpose for the CCB function 53
Slide 89: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • • • • • The CCB’s Scope of Authority Membership requirements for CCB The CCB’s operating procedures The CCB’s decision-making process Process for communication of findings to senior management and the board of the organization, as well as to stakeholders (which may fall outside senior management and the board) Concept of Risk-Based, Cost-Effective Controls Controls, or measures taken in an environment to protect its critical assets (which include people, processes, data, technology, and facilities), are implemented to have the greatest impact on higher risk areas within the organization. Tactically, this makes the most sense from a cost-effective perspective, as it is nonsensical to apply significant controls around any issue that is of little consequence to the organization. Controls must be evaluated for their effectiveness against their cost to the organization in terms of loss of the asset, resourcing costs, and so on. High cost, low impact controls should be avoided. Validation of Security Controls Prior to the implementation of a new or updated security control in the production environment, the control must be properly validated in a test environment that is separate from the production environment. In order to correctly assess whether the security control functions effectively, the test environment must reasonably approximately the production environment. It is advisable to construct a formal test plan, which includes all aspects of the control that are being tested. The test plan must be “signed off” once testing is completed, regardless of whether the testing was successful. All notes taken during testing must be saved as work product and attached to the test plan. Configuration Management Plan Development and Implementation Because configuration management is so integral to the proper operation of a secure environment, a formalized and documented plan must be developed, implemented, and monitored for successful completion. A configuration management plan consists of the following characteristics: • The plan must be actionable. • The plan must be achievable in an appropriate time frame. • The plan must account for sufficient resources to complete the tasks detailed in the plan. 54
Slide 90: Security Operations and Administration • The plan must detail sufficient security controls around the configuration management process. • The plan must include implementation specifics. • The plan must include a proper sampling plan, if staged configuration management is proposed. • The plan must include an appropriate and formalized testing plan, complete with a process for reporting results. • The plan must detail the process for enforcement and monitoring of activities in contained within the plan. • The plan must specify the chain of approvals for contents the plan itself, up to and including successful completion of the plan elements. Once the plan has been approved, it can be implemented into the environment. Affected business units must be notified and advised how the change will affect operations, prior to its implementation. Business units may have concerns that can be addressed in the current configuration plan. Post-implementation, the plan must be enforced and monitored to ensure it is operating effectively. Impact of Security Environment Changes Implementing changes to the security environment within an organization can bring about both positive and negative impact to operations and the business units that perform them. Prior to implementation of, or any change to, security controls within the organization, an impact analysis must be performed to determine whether there are any serious consequences and whether these consequences can be mitigated either through the use of an alternative security control. It is important to remember that impact is related to risk; that is, a high risk-high impact change to the environment must be evaluated closely and blessed by senior management prior to its implementation. It is advisable to lessen impact to the organization through the use of proper security education surrounding the change. This will facilitate its incorporation into daily operations and will speed staff in making the transition to the new environment. Patches, Fixes, and Updates Validation Patching is typically incorporated into the general configuration management plan; however, it is also acceptable to create a separate plan for patching and general system remediation and changes. Regardless of whether a separate plan is used, validation of these activities must also be formally documented, as presented above in the section on configuration management. 55
Slide 91: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Secure System Development Life Cycle Introduction In the past, technical security considerations have been the domain of the network or system administrator. However, with the publicizing of the detrimental effects that “bad code” can have on the technical environment within the organization, it has become apparent that application development personnel must be trained, and subsequently must code, to security standards. This chapter discusses the secure system life-cycle design, including information surrounding applications and secure enterprise architecture design that can contribute to an organization’s security assurance. As such, four contributing factors must be taken into account: the Development Life Cycle, Systems Acceptance, Systems Accreditation, and Systems Certification. All will be discussed within this section. The System Development Life Cycle The System Development Life Cycle is used to provide a foundation for each phase of an application development project. Many professionals, such as application developers, security personnel, database or system analysts, end users, and management are included as stakeholders in this life-cycle. Because the life cycle is a formal and documentable method for performance of secure application development, it may also serve, to some extent, as a project management tool. The difference between “system life cycle” and “system development life cycle” is that we as security professionals are concerned not only with the development phases but also with the operation and maintenance phases (after the application has been developed) as well. The system development life cycle is really only the development project; it does not include operations and maintenance. Most standards and regulations make mention of the requirement for a “formal software (or systems) development life-cycle (SDLC).” The requirement is based on the notion that application development (and indeed, the development of entire information systems) should be conducted in a standardized and structured way. Successful implementation of this life cycle will provide a framework for security, infrastructure and development professionals to proceed from prototype to completed project in an organized and documentable (i.e., formal) fashion. 56
Slide 92: Security Operations and Administration © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.1 Project Planning and Initiation According to (ISC)2, there are eight stages to the system life cycle. They are: Project Initiation and Planning, Function Requirements Design, System Design Specifications, Develop and Document, Acceptance Testing, Implementation, Operations and Maintenance Support, and Disposal. Figures 2.1 through 2.4 demonstrate security focus that is required as part of the process for appropriate system development, testing, and implementation. It is important to note that security requirements are considered from the beginning of development and progress apace with development, testing and implementation of the finalized product. During project initiation, three steps are performed. • Identification of user needs • Evaluation of alternatives for system development • Selection of an appropriate approach to perform the system development During the identification of user needs, the development team works with the affected business unit(s) and, as required, management, to ensure that the system developed will address user needs. Post needs identification, the development team identifies alternative methods for the building of an appropriate system for the affected unit(s). Once all alternative approaches have been identified, an approach is selected that will meet the approval of the affected unit(s). 57
Slide 93: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.2 Define Function Requirements This preparatory phase must also include security analogs to each of the steps in order to “bake in” security considerations for the system. When business unit needs are identified, security needs should be identified along with them so they can be addressed at the same time. Likewise, as alternative development approaches are being evaluated, the risks inherent to that approach must also be identified, in order to facilitate successful completion, implementation and functionality of the end product. When an approach is approved and selected, it is important to build the security framework upon which subsequent development efforts will be built. Standards, such as the ISO17799 and ISO20000, and best practice frameworks and methods, such as the Capability Maturity Model for Integration (CMMI) and the Information Technology Infrastructure Library (ITIL) can be leveraged during the creation of the security framework. When an appropriate approach has been selected, it is time to prepare the project plan for the development of the system. It is important to ensure that security considerations are also included in the project plan so they are addressed during development. The development team then conducts sessions with the affected unit(s) and management, as appropriate, to define the requirements of the system to be developed. During this requirements analysis activity, risk and contingency analyses should also be performed, in order to provide the development team with information about potential risks to functionality and development. When risks and contingencies have been identified, a testing strategy can be developed, along with security 58
Slide 94: Security Operations and Administration © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.3 System Design Specifications testing. This provides evidence that functionality is appropriate and controls are implemented and operating effectively in the system and its environment. At this time, strategies for acquiring product can also be developed. Security requirements for the product can be detailed in any documentation produced, such as requests for proposals, service level agreements and so forth. At the conclusion, a formal baseline can be established, both for system development and security requirements present in that development. When the preliminary system planning is completed, the design specifications can be formalized. This includes: developing a complete and detailed design, including appropriate security specifications; reviewing the test plan and updating it as required to meet both functional and security requirements; and establishing a documented and formal baseline, including security components, for measurement. When the design and test plans are completed, system components can be tested using the plan. This includes the testing of security-related components, as identified in the test plan. The development and testing teams use this information to validate both the system performance and the security components that have been built into the system. If the tests prove that additional work is necessary, this work will be completed by the development team and resubmitted for testing. Once the testing is successfully completed, the system can be installed, complete with the controls identified as 59
Slide 95: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.4 System Acceptance Process required within the system design. At this time, manuals for the system can also be completed. Post-completion of the documentation and installation, acceptance testing occurs. Should the testing prove successful, the system is accepted; if it is not successful, remedial work is completed by the development team to ensure system acceptance. As part of the completion of the project, the security components and controls are reviewed again to ensure proper implementation and operating effectiveness. Risk Assessment It is typical for an organization to conduct a “risk assessment” prior to, or sometimes during, application development, in order to evaluate: • Threats to its assets • Vulnerabilities present in the environment • The likelihood that a threat will “make good” by taking advantage of an exposure (or probability and frequency when dealing with quantitative assessment) • The impact that the vulnerability being realized has on the organization • The risk associated with each threat successfully exploiting a vulnerability Why perform a risk assessment? Without knowing what assets are critical and, likewise, those that are most at risk within an organization, it is not possible to protect those assets appropriately. For example, if an organization is bound by Sarbanes-Oxley regulations, but does not know how financial 60
Slide 96: Security Operations and Administration reporting may be at risk, the organization may make significant mistakes such as neglecting to protect against certain risks or applying too much protection against low-level risks. Qualitative Risk Assessments Organizations have the option of performing a risk assessment in one of two ways; either “qualitatively” or “quantitatively.” Qualitative risk assessments produce valid results that are descriptive versus measurable. A qualitative risk assessment is typically conducted when: • The risk assessors available for the organization have limited expertise. • The time frame allotted for risk assessment is short duration. • The organization does not have trend data readily available that can assist with the risk assessment. Analysis of risk can include matching a threat to a vulnerability, matching threats to assets, determining how likely the threat is to exploit the vulnerability, and determining impact to the organization in the event the exploit is successful. Analysis also includes a matching of current and planned countermeasures (i.e., protection) to the threat-vulnerability pair. When the matching is completed, risk can be estimated. In a qualitative analysis, the product of likelihood and impact produces the “level” of risk. The higher the risk level, the more immediate is the need for the organization to address the issue to protect the organization from harm. Quantitative Risk Assessments As an organization becomes more sophisticated in its data collection and retention, and staff also becomes more experienced in conducting risk assessments, an organization may find itself moving more towards quantitative risk assessment. The hallmark of a quantitative assessment is the numeric nature of the analysis. Frequency, probability, impact, countermeasure effectiveness, and other aspects of the risk assessment have a discrete mathematical value in a pure quantitative analysis. It is clear to see the benefits, and the pitfalls, of performing a purely quantitative analysis. Quantitative analysis allows the risk assessor to determine whether the cost of the risk outweighs the cost of the countermeasure, in mathematical rather than descriptive terms. Purely quantitative analysis, however, requires an enormous amount of time and must be performed by assessors with a significant amount of experience. Additionally, subjectivity is introduced because the metrics may also need to be applied to qualitative measures. Methods Three steps are undertaken in a quantitative risk assessment, after the initial management approval, construction of a risk assessment team, and the review of information currently available within the organization. Single Loss Expectancy (SLE) must be calculated to provide an estimate of loss. Single loss expectancy is defined as the difference between 61
Slide 97: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® the original value and remaining value of an asset after a single exploit. Losses can include lack of availability of data assets, due to data loss, theft, alteration, or denial of service. Next, the organization would calculate the Annualized Rate of Occurrence (ARO). This is done to provide an accurate calculation of Annualized Loss Expectancy (ALE). ARO is an estimate of how often a threat will be successful in exploiting a vulnerability over the period of a year. When this is completed, the organization calculates the ALE. The ALE is a product of the yearly estimate for the ARO and the loss in value of an asset after a SLE. Given that there is now a value for SLE, it is possible to determine what the organization should spend, if anything, to apply a countermeasure for the risk in question. Remember that no countermeasure should be greater in cost than the risk it mitigates. Countermeasure cost per year is easy and straightforward to calculate. It is simply the cost of the countermeasure divided by the years of its life (i.e., use within the organization). Finally, the organization is able to compare the cost of the risk versus the cost of the countermeasure and make some objective decisions regarding its countermeasure selection. Once risk has been determined, additional countermeasures can be recommended to minimize, transfer, or avoid the risk. When this is completed, the risk that is left over after countermeasures have been applied to the organization to protect against the risk is also estimated. This is the “residual risk,” or risk left over after countermeasure application. Selecting Tools/Techniques for Risk Assessment It is expected that an organization will make a selection of the risk assessment methodology, tools, and resources (including people) that best fit its culture, its personnel capabilities, its budget, and its timeline. Many automated tools, including proprietary tools, exist in the field. While automation can make the data analysis, dissemination and storage of results easier, it is not a required part of risk assessment. If an organization is planning to purchase or build automated tools for this purpose, it is highly recommended that this decision be based on appropriate timeline, resource skill sets for creation, implementation, maintenance, and monitoring of the tool(s) and data stored within, long term. Risk Assessment Steps Identification of Vulnerabilities It is common to identify vulnerabilities as they are related to people, processes, data, technology, and facilities. 62
Slide 98: Security Operations and Administration Examples of vulnerabilities could include lack of physical security within a facility, inadequate validity checking in financial transaction software, and so on. Identification of Threats Threat sources have been identified by a number of groups, but can be compiled into a few categories: • • • • • Human Natural Technical Physical/Environmental Operational/Functional Each category can be expanded with specific threats, as follows in the examples: • Human: malicious outsider, errors made by human intervention, cultural issues, such as a strike • Natural: fire, flood, or other natural disasters Determination of Likelihood Likelihood, along with impact, determines risk. Likelihood, as stated by the National Institute of Standards and Technology (NIST) and others can be “measured” by the capabilities of the threat and the presence or absence of countermeasures. Initially, organizations that do not have trending data available may use an ordinal scale, labeled High, Medium, and Low to score likelihood rankings. These are actually qualitative elements. Determination of Impact Impact can be ranked much the same way as likelihood. The main difference is that the impact scale is expanded and depends upon definitions, rather than ordinal selections. Definitions of impact to an organization often include loss of life, loss of dollars, loss of prestige, loss of market share and other facets. It is highly recommended that the organization take sufficient time to define and assign impact definitions for High, Medium, Low or any other scale terms that are chosen. Determination of “Risk” Risk is determined by the product of likelihood and impact. For example, if an exploit has a likelihood of 1 (High) and an impact of 100 (High), the risk would be 100. Using the same mapping scale as for impact, this would be the highest exploit ranking available. These scenarios (high likelihood, high impact) merit immediate attention from the organization. As the risk calculations are completed, they can be prioritized for attention, as required. Note that not all risks will receive the same level of attention, based on the organization’s risk tolerance and its strategy for mitigation, transfer, acceptance, or avoidance of risk. Reporting Findings Once the findings from the assessment have been consolidated and the calculations have been completed, it is time to present 63
Slide 99: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® a finalized report to senior management. This can be done in a written report, by presentation, or “outbrief,” or by both means. Written reports should include an acknowledgment to the participants, a summary of the approach taken, findings in detail (either in tabulated or graphical form), recommendations for remediation of the findings and a summary. Countermeasure Selection It is important for the organization to appropriately select countermeasures to apply to risks in the environment. Many aspects of the countermeasure must be considered in order to ensure it is the proper fit to the task: • • • • • • • • • • • • • • • • • Accountability Auditability Publicly available, simple design Trusted source Independence Consistently applied Cost effective Reliable Distinct from other countermeasures Ease of use Minimum manual intervention Sustainable Secure Protects confidentiality, integrity and availability of assets Can be “backed out” in event of issue Creates no additional issues during operation Leaves no residual data from its function While this list appears rather lengthy, it is clear that countermeasures must be above reproach when in use for protection of an organization’s assets. Implementation It is important to note that, once risk assessment is completed and there is a list of remediation activities to be undertaken, an organization must ensure that it has personnel with appropriate capabilities to implement the remediation activities, as well as to maintain and support them. This may require the organization to provide additional training opportunities to personnel involved in the design, deployment, maintenance, and support of security mechanisms within the environment. In addition, it is crucial that appropriate policies, with detailed procedures that correspond to each policy item, be created, implemented, maintained, monitored and enforced in the environment. It is highly recommended that the organization assign accountable resources to each task and track tasks over time, reporting progress to senior management and allowing for time for appropriate approvals during this process. 64
Slide 100: Security Operations and Administration Risk Management Once the organization has performed risk assessment activities, senior management can determine how best to deal with the risk presented. This is the discipline of “risk management.” Methods for dealing with risk are presented below. Risk Avoidance Risk avoidance can be defined as the practice of coming up with alternatives so that the risk in question is not realized (it is “avoided”). For example, if an individual wanted to avoid the risk of sports injury, he or she would not participate in sporting activities. Risk Transfer Risk transfer can be defined as the practice of passing on the risk in question to another entity, such as an insurance company. It is important to note that the transfer of risk may be accompanied by a cost. An example would be liability insurance for a vendor or the insurance taken out by companies to protect against hardware and software theft or destruction. Risk Mitigation Risk mitigation can be defined as the practice of the elimination, or the significant decrease, in the level of risk presented. For example, in order to lessen the risk of exposing personal and financial information that is highly sensitive and confidential, organizations put countermeasures in place, such as firewalls, intrusion detection/prevention systems, and other mechanisms to deter malicious outsiders from accessing this highly sensitive information. Risk Acceptance In some cases, it may be prudent for an organization to simply accept the risk that is presented in certain scenarios. Risk acceptance can be defined as the practice of accepting certain risk(s), typically based on a business decision that may also weigh the cost versus the benefit of dealing with the risk in another way. The decision to accept risk should not be taken lightly, or without appropriate information to justify the decision. The cost versus benefit, the organization’s willingness to monitor the risk long-term and the impact it 65
Slide 101: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® has on the outside world’s view of the organization must all be taken into account when deciding to accept risk. Software Development Methods The Waterfall Model The Waterfall model (see Figure 2.5) for software development was created in the 1970s and is typically considered the oldest of the process-oriented development methods reported. It is a “phase-based” approach, meaning the completion of each heralds the commencement of the next phase; that is, development is conducted serially. Because of the serial nature of this development method, it does not scale well to large, complex projects. Another drawback of serial development is that it extends the time frame of the project, therefore usually making it an unsuitable method for projects which must developed in a short time frame (e.g., six months or less). The main advantage of using this method is that each phase is completed, including documentation, prior to the next phase commencing, therefore giving the developer a good deal of data to draw from. An example of an organization that has used the Waterfall model is The National Aeronautics and Space Administration (NASA), for example, has used the Waterfall model its space exploration program. The Waterfall model contains the following five stages: • • • • • Requirements analysis and definition System and software design Implementation and “unit” testing System testing Operation and maintenance These stages will be discussed in detail below. Requirements Analysis and Definition Conducting a requirements analysis allows an organization or a team to get to the heart of the problem to be solved. Requirements are determined by interactions with senior management, the business units, and the end users affected and are typically fairly high-level to start. Requirements are stated in terms of business rules, not technology. It is important to “lock down,” as much as possible, requirements from a development project in advance, so that there are fewer deviations, or changes, along the way to completion of the project. 66
Slide 102: Security Operations and Administration System and Software Design Once the requirements have been gathered, documented, and finalized, a design implementing the requirements can be completed. All of the requirements documented during the requirements analysis phase must be appropriately addressed by the system design. It is important that the design be detailed enough to ensure implementation is achievable, with the minimum of difficulty, and limited to no necessity to go back to those stakeholders who assisted with requirements gathering due to lack of information. Development The job of writing code occurs in this phase. It is critical that the developers responsible for the project be well-versed in secure coding procedures, such as those embraced by the Open Web Application Security Project (OWASP). In addition, code should be developed to specifications (i.e., requirements analysis) and, if this is not possible, any changes must be documented, typically through a formal change control process. Testing and Implementation Source code must never be implemented without appropriate testing. To do so puts the organization at risk for unplanned outages, the “breaking” of © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.5 The Waterfall Model 67
Slide 103: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® functionality critical to the organization’s operations, and other hazards. Documented test plans must be prepared by the development team and exercised by organizational staff not part of the development team. Test plans should include functional testing at all levels, including unit, system and user acceptance testing. When the test plans have been completed, the tester must sign the plan to indicate it has been exercised. Any errors detected during the test must also be documented on the plan, corrected and retested by personnel not responsible for the first test (and not part of the development team) prior to implementation. If it is necessary to make changes to the code for any reason, formal chance control process must be followed. Operation and Maintenance Operation and maintenance of the code fall into the final step of the Waterfall method. The Iterative Development Model The Iterative Development model (see Figure 2.6) is actually a fragmented Waterfall model. Each fragment consists of a smaller component of the foundation. While this method allows for just-in-time refinements of the development process, including requirements analysis, project design and coding, there is a danger that the project may exhibit significant scope creep as a © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.6 The Iterative Development Model 68
Slide 104: Security Operations and Administration result, particularly if not all requirements are known up front or if there is an excessive amount of change requested during development. This type of project must be closely managed to avoid these pitfalls. The Exploratory Model In the Exploratory model, hypothetical requirements provide the design and implementation for the project. This can happen when requirements are not known prior to the project commencement. As requirements are discovered, a series of rapid iterations of the code are completed to incorporate the requirements. Because there is an absence of formalized requirements, verification of the design and implementation are conducted based on the resultant code base. The Exploratory model is simple in its construction; it is composed of the following steps: • • • • Initial Specification Development System Construction/Modification System Testing System Implementation It is difficult to determine whether the Exploratory method will yield an appropriate result. Due to the absence of specificity in the requirements and design, it is not possible to verify whether it is the most cost-effective approach for the development team. In addition, the code produced is often less than elegant, as pre-planning was not performed. This model can also only be used with languages that allow for rapid code development, such as LISP. The Rapid Application Development (RAD) Model RAD attempts production-ready software at highly controlled time frames, through the development of an application prototype. For projects where deadlines are very strict, this development method may prove useful. It is critical to tightly control the quality of the software produced in this method as well, given that rapid production may also lead to poor design and the resulting code from that design. The Spiral Model The Spiral model is a combination of both the Waterfall and Prototyping methods. Similar to prototyping, an initial version of the application is developed. However, the development of each version is carefully designed using the Waterfall model. A positive feature of this development effort is 69
Slide 105: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® the ability to conduct a risk assessment activity during each phase of the project. The information obtained from the risk assessment is then used to update schedules, costs and so on. If at any time during the risk assessment activities it is determined that the project is in jeopardy, it can be cancelled. The Spiral model can be identified by the presence of following steps: • • • • • Project Objectives Risk Assessment Engineering and Production Planning and Management (feedback opportunity for the stakeholders) The Reuse Model The hallmark of the Reuse model of software development is the “reuse” of existing coded modules to complete the task. For those who have had experience with object-oriented development, this model seems second-nature. Object-oriented programming is best suited for the Reuse model, as the objects stored within the object libraries can be exported, modified, and reused at will. Libraries of software modules are also built and maintained in the Reuse model. These libraries consist of procedural modules or database modules. Modules that do not currently exist within the libraries can be built by the developer and stored in the appropriate library for later use. The Reuse model consists of the following steps: • • • • • • • • Definition of Requirements Definition of Objects Collection of Objects from Existing Code Creation of Customized Objects Not Currently Existing within the Module Libraries Prototype Assembly Prototype Evaluation Requirements Refinement Objects Refinement The Computer Aided Software Engineering (CASE) Model The CASE model was designed in the 1970s and embraced the use of computers assisting with software design, development, and maintenance activities. CASE tools have been developed to assist with both visual and object-oriented programming efforts. CASE development is most often used on significantly complex development projects, which are identified by the use of many technical components and personnel. 70
Slide 106: Security Operations and Administration © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.7 Extreme Programming Project Diagram There are many obvious advantages to the use of CASE development methods for sizable projects. Project participants have an opportunity to work towards common goals for each program module. This sharing of knowledge and resources may result in the lowering of project costs over time. In addition, code reuse is made possible, thereby saving additional time and effort on the part of the development team. Features embedded in CASE tools include code and relational/logical database modeling simulations, object-oriented notation, and diagramming capabilities, among others. Extreme Programming The developer of the Extreme Programming model, Kent Beck, envisioned the use of this model to assist developers working in small groups with limited time frames, looming deadlines, and requirements that are changing rapidly (see Figure 2.7). This approach is highly disciplined and encourages developers to add functionality only as requested. This puts a functional limitation on the code itself, which enables relatively simple tracking through code improvement, testing, and implementation. In addition, this method puts significant emphasis on customer satisfaction. Security Management Planning For an organization to appropriately plan for managing security within its environment, it should carefully consider, at the least, the following costs to determine next steps: 71
Slide 107: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • • • • • Identify the initial investment in security management Calculate ongoing costs Identify the effect on internal and external (public) perception Identify impact on confidential information Identify impact on the organization’s intellectual property In addition to the benefits of continued maintenance of security within the organization, it should also consider other potential benefits to the organization. They may include: • Enhanced perception of the organization to internal and external stakeholders • Potential workload reduction for personnel, particularly in Risk Management/Internal Audit, Compliance, Security, Information Systems, Human Resources, and Senior Management • Improved business partner access • Improved remote access • Creation, implementation, maintenance, and monitoring of common data locations, particularly important to sensitive data Once the costs and benefits are presented to senior management, it may be the job of the security professional to promote buy-in from the organization’s business units. In order to accomplish this, the professional must: • Understand the business of the organization • Understand what is important to the stakeholders, both internal and external, including clients and business partners • Be able to communicate how security can help them achieve their objectives while remaining secure Creating the Security Statement One of the first elements in security management planning is developing an overall general organization security statement. The statement is a highlevel security “mission statement” that communicates the organization’s sensitive and critical assets, as well as the most significant risks to those assets. The organization utilizes the security statement to create operational policies and procedures. Examples of operational policies include: • • • • • E-Mail Policies Telecommuting Policies Remote Access Policies Business Continuity Policies Fraud Policies 72
Slide 108: Security Operations and Administration Security Policy Creation and Maintenance In order to communicate management’s expectations with regard to responsibilities for security within the organization, an appropriate policy foundation must be created. This foundation is comprised of “policy deliverables,” which include policies, standards, procedures, guidelines and plans, in addition to working documents that provide background information for the policy deliverables. Creation of policy deliverables occurs within a life cycle, much like technical life cycles, such as the software development life cycle. Life cycle stages include: • • • • • • Identification of the need for a policy deliverable Design the policy deliverable Create the policy deliverable based on the design Obtain appropriate approvals for the policy deliverable Perform training on the policy deliverable within the organization Complete implementation of the policy deliverable, including the communication of the policy deliverable to the organization Maintenance of policy deliverables, either as a scheduled maintenance for a semiannual or annual review of the policy foundation, or as an update of policies for operational reasons, occurs in much the same fashion as detailed for creation. Steps that may be abbreviated, dependent upon the state of the existing policy deliverable, might include identification or design. Security Policy Implementation Policy deliverable implementation can be accomplished in a number of ways within an organization. At minimum, the following activities must occur: • A formalized and documented implementation plan must be produced; this provides the format against which to measure effectiveness of the implementation, as well as effectiveness of the policy deliverables themselves. • Dedicated resources must be available to implement the policies. • Senior management must formally communicate to the environment pre-implementation that it has approved these policy deliverables and will support actions required to enforce the policy deliverables. • Policy deliverables must be rolled out to the entire organization/those with need-to-know through more than one medium. Examples might be through a Web site and distribution by e-mail to all concerned persons. • A timetable for implementation must be communicated to all affected persons. • Formal, documented, mandatory training on the policies must be rolled out prior to implementation finalization. A formal signoff list of attendees must be kept for auditing purposes. 73
Slide 109: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Security Procedure Development and Documentation The development and formal documentation of security procedures is identical to the process documented above for the creation of policy deliverables (e.g., recall that policy deliverables include procedures). It is important to remember that procedures differ from policies in that they are a step-by-step tactical representation of “how” a security concern is addressed within an environment. Organization Security Evaluation and Assistance The Protection Profile A Protection Profile (PP) is document detailing security requirements that are specific to certain customer needs for security. Protection Profiles are becoming more prevalent for software and database applications. These profiles are implementation-independent. Examples include Oracle’s Database Management System Protection Profile, the UK Controlled Access Protection Profile, and the UK Labeled Security Protection Profile. Each Protection Profile described the target environment, security goals, functions, and assurance (confidence) requirements. Protection Profiles must also go through a Common Criteria evaluation and those profiles that successfully navigate the evaluation are included in a central registry for use by the public. Uses will likely include prescriptions for developers with respect to best practices for security for a product or system. It is the intent of the supporting sponsors to port this information to a Web site for ease of use. This site will also help sponsors to build relevant security targets more efficiently. Protection Profile structure is as follows: • • • • • Description, to include the information protection issue Rationale, to include a justification and security policy support Functional requirements, such as roles and responsibilities Development at all phases of the assurance requirements Evaluation of the assurance requirements Protection Profile development is as follows: • Conduct a security analysis of the environment, to include threats and vulnerabilities, expected use, assumptions about the environment, and any relevant information security including documentation (policies, procedures, guidelines, standards, compliance objectives, and so on). • Conduct requirements analysis and synthesis, including those for functional and assurance components. 74
Slide 110: Security Operations and Administration Protection Profile analysis is conducted by taking into account: • • • • • Technical soundness Use Evaluation capacity Uniqueness from other profiles Consistency with other profiles The following represent the Common Criteria evaluation assurance classes. • EAL-01 — Functionally Tested. This assurance class describes assessment of relevant security functionality, through the use of function and interface specifications of the target to understand the security behavior. The assessment is validated through independent testing of the security functionality. • EAL-02 — Structurally Tested. This assurance class describes assessment of relevant security functionality, through the use of function and interface specifications, adding the high-level design of relevant subsystems from the target to understand the security behavior. Independent testing of security functionality, “black box” testing formalized documentation, and evaluation of potential vulnerabilities, as formally documented by developers conducting the search, are hallmarks for this assurance class. • EAL-03 — Methodically Tested and Checked. Results from the assessment are supported by “gray box” testing, as well as the independent confirmation of test plan results as documented by the developer and formal substantiation that development personnel have considered appropriate potential vulnerabilities. Environmental controls and configuration management relative to the target are also required. • EAL-04 — Methodically Designed, Tested, and Reviewed. Assessment in this assurance class evaluates the low-level design of the program modules of the target, as well as the addition of a subset of the implementation. Testing is validated through an independent search for potential vulnerabilities. Development controls include a life-cycle model, identification of tools, and automated configuration management. • EAL-05 — Semi-formally Designed and Tested. Assessment at this assurance class includes complete review of the product/system implementation itself. Assurance objectives are supplemented by a formal model, as well as a “semiformal” presentation of the functional specification, the high-level design, and a semiformal demonstration of correspondence. The search for vulnerabilities must include formal evidence of appropriate resistance to unauthorized access or attack. Covert channel analysis and a modular design of the product/system are also required. 75
Slide 111: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • EAL-06 — Semi-Formally Verified Design and Tested. Assessment of this assurance class is facilitated by a modular, layered approach to design. A structured presentation of the implementation is also required. The independent analysis of potential vulnerabilities must provide formal evidence that there is high resistance to unauthorized access or attack. The search for covert channels must be proven to be systematic. Environmental and configuration management controls are further identified, documented, and formalized. • EAL-07 — Formally Verified Design and Tested. The formal model is supplemented by a formal presentation of the functional specification and high-level design showing correspondence. Formal verification of developer “white box” testing and complete independent confirmation of developer test results are required for this assurance class. Complexity of the design must be minimized in all ways possible. Modes of Operation System High Mode In system high mode, all systems and peripheral devices are classified. They are subsequently protected at the highest level of classification of data resident on the system. For example, if a system houses top secret information, but also holds information that the public can view, the system is classified as top secret. Users who have been authorized to a system have clearance and approval to view data on that system; however, should there be information resident on the system for which the user has no “need-to-know,” access would be denied. Compartmented Mode The following are characteristics of systems operating in compartmented (“partitioned”) mode: • Each user with access must meet the relevant security criteria for the system. • The user has a predetermined access level for the system. • Access is authorized by “need-to-know” only. • User access may be revoked based on criticality of the data resident on the system. • Comprehensive documentation is present that tracks the data access granted for each user. Multilevel Secure Mode (MLS) The following are characteristics of systems operating in MLS mode: 76
Slide 112: Security Operations and Administration • Not all personnel have approval or need-to-know for all information in the system. • Users are not allowed to access classified data at different classification levels. • In order to combat “data leakage,” processes are not allowed to interact. • These are the only systems on which multiple levels of classified data can exist. Operating Utilities and Software Systems are managed by software called “operating systems.” Examples are Windows and all its flavors (NT, 2000, 2003, XP, and so on), Linux, Unix, and others. Operating systems manage subsystems that are functional and resident on a system, such as: • • • • Software utilities Applications File systems Access controls for users, programs or other systems Services provided by operating systems include: • • • • Program execution Access to I/O devices Controlled access to files (based on credentials) Access to the system itself, as well as to appropriate interconnected systems • Error detection, potential correction and response • Accounting functions Operating systems also control hardware resources, such as: • The Central Processing Unit (CPU) • Memory • I/O and storage devices The Central Processing Unit The CPU is bound by processing states. These states are the Stopped/ operating state, the Wait/running state, and the Masked/interruptible state. The Stopped/Operating state is marked by a process not operating, or a computer waiting or running. The Wait state is marked by a wait, as instructions have not been executed or the system is waiting for interrupts or data. In the Running state, instructions are being executed and interrupts are being taken. In the Masked/interruptible state, if the masked bits are not set, the interrupts are disabled (masked bits are off). This is 77
Slide 113: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® commonly called the system IRQ (Interrupt Request). CPU configurations include multitasking configurations and multiprogramming configurations. Multitasking is the performance of two or more tasks concurrently. Multiprogramming is the processor-driven interleaved execution of two or more applications. Memory Memory management is a critical task for systems. Requirements for memory management include: • • • • • Relocation Protection Sharing Logical Organization Physical Organization There are three types of memory addresses: logical, relative, and physical. Logical memory addresses require a translation to physical addresses. They are a reference to a previous data location in memory. Relative addresses are expressed as a memory location relative to a known point. Physical addresses are the actual location in memory; they are also known as the “absolute” address. Service Level Agreement Compliance Non-Disclosures (NDA) NDAs place restrictions on dissemination of corporate information to outside and inside interests. Non-disclosures are typically used to communicate expectations relative to the communication of sensitive information, such as information covered by regulation (e.g., health information, financials), as well as intellectual property, and so on. Non-Competition Non-competition agreements present the signer with restrictions on work completed for competitors, the ability to contract with the company’s clients or to hire away current employees of the company. Service Level Agreements (SLA) SLAs are formalized, contractual documents that ensure that an organization receives the services for which it has contracted. For example, organizations may require external vendors, especially those responsible for network operations, business continuity/ disaster recovery, or forensics work, to sign a contract stipulating that it will ensure the organization is able to function under duress without undue downtime or loss of its assets. Internal service level agreements can include formalization of services provided to the organization from infrastructure, network, or application development units. 78
Slide 114: Security Operations and Administration User Security Awareness Education Security Awareness Most, if not all people within an organization, have some idea about what they can do to protect themselves, the organization and its assets from harm; however, because people differ in their interpretations, opinions, outlooks and expectations, it is critical that senior management provide a single, unified message with regard to security expectations. That is, senior management must make employees, contractors, business partners, vendors, and anyone else with access to corporate assets “aware” of information security requirements. This can only be done through appropriate security awareness training. In order to ensure a single interpretation of security requirements, all applicable parties must complete this mandatory awareness training. Awareness training should be conducted periodically, either online or in person, and no less than once per year. Both new hires and established personnel must complete security awareness training. Once the initial training is completed, it is advisable to present applicable parties with security “reminders.” These can take the form of posters, key chains, columns in employee publications, the establishment of Security Awareness Day, and so on. Contests and awards help to motivate personnel to comply with security requirements. It is important to note that security topics should be changed often, so that new material can be presented to reflect current issues and also to ensure that personnel maintain their interest. Security Training Unlike general security awareness training, security training assists personnel with the development of their skills sets relative to performance of security functions within their roles. A typical security curriculum in a mature organization will include specialty classes for individuals performing specialized roles within the organization, such as those in Information Systems, Accounting, and others. Even within these business units, specialized training will occur. For example, in the Information Systems area, it would be advisable for network staff responsible for maintenance and monitoring of the firewalls, intrusion detection/prevention systems and syslog servers to be sufficiently trained to perform these duties. Let’s say senior management determined there were no funds available for training. What would be the result? Well, typically, motivated staff would perform some on-the-job learning; however, it may not be sufficient to perform the job duties adequately. As a result, the organization is breached and sensitive information is stolen. Who would be 79
Slide 115: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® at fault in this case? The answer is that senior management is always ultimately responsible in the organization for information security objectives. Senior management failed, in this case, to adequately protect the organization by refusing to properly train staff in their respective security duties. Any legal ramifications would fall squarely upon management’s shoulders. Let’s examine the previous situation in another way. Let’s say that the personnel in question indicated to management that, although no paid training was available, they felt comfortable that they could perform the security functions for which they were responsible. To demonstrate, they performed the requisite functions for IT management to demonstrate capability. All is well until the organization is breached some months later and confidential information stolen. Senior management returns to Information Systems management and asks the director of Information Systems to investigate. During her investigation, she discovers that patching has not occurred for the past three months. When staff were asked about the incident, no satisfactory answer could be given. Who would be responsible for the breach in that event? The answer is: senior management is always ultimately responsible for information security within the organization; however, senior management held the network team accountable for failing to maintain patching levels and promptly fired them from their positions. Ensuring that a resource is properly trained can assist an organization in assigning accountability for the satisfactory completion of security tasks for which they are responsible. The organization must also keep in mind that training should be closely aligned with security risk management activities. In doing so, the training may result in partial or complete offset of the risk within the organization. Security Education Security education (specifically, in this case, Information Security) revolves around the education of a potential or experienced security professional along career development lines and, as the SSCP Administrative Domain course points out, “provides decision-making and security management skills that are important for the success of an organization’s security program.” Security certifications versus vendor certifications, may fit into this category. Certifications such as the SSCP, CISSP®, CISA, CISM, GIAC, and others are related to the discipline of security for the practitioner. The benefits of this training have already been presented. Costs of the training, relative to benefit received by the personnel and organization, must be evaluated before training begins. Equally important are curricula that have been introduced into the universities through the Federal government and other benefactors, implemented as Bachelor’s, Master’s, and PhD programs. Many of these programs present 80
Slide 116: Security Operations and Administration both theory and hands-on coursework to the student. Topics covered in these programs may include: policy and procedures design and development, security assessment techniques, technical and application security assessment techniques, social engineering; malicious software identification and eradication, incident response, disaster recovery, and security program development. The benefit derived from this education is self-evident; a practitioner versus a technician is created. It is important to note, however, that education of this type is typically two to six years in duration and takes significant time and resources to successfully complete. An alternative may be to train professionals on a university course-by-course basis in information security. This may be a practical alternative, given the need within the organization. Security Awareness and Training Plan Security awareness training must be formally documented as a security requirement within an organization. This minimally requires the completion of a training plan that precedes the implementation of new or updated security controls, as well as includes provisions for periodic awareness training as required for operational and compliance reasons. Code of Ethics Some companies require employees to sign an Ethics (or Business Ethics) statement, which may contain overlapping information with an organization’s acceptable use policy. Many ethics agreements are a synthesis of the Acceptable Use Policy, non-disclosure and non-competition agreements, among other documents. (ISC)2 Code of Ethics (ISC)2 has prepared an ethics statement which must be adhered to as part of its requirement for the certification of security practitioners with CISSP or SSCP designation. A formal, signed copy of this ethics statement is required for each candidate prior to certification. A complete copy of the ethics statement can be obtained directly from (ISC)2. RFC 1087: Ethics and the Internet The policy behind this ethics statement is represented here in its entirety directly from the RFC 1987 Web site (www.rfc-archives.org). Internet Architecture Board (IAB) Statement of Policy is as follows: The Internet is a national facility whose utility is largely a consequence of its wide availability and accessibility. Irresponsible use of this critical resource poses an enormous threat to its continued availability to the technical community. The U.S. Government sponsors of this system have a fiduciary responsibility to the public to allocate government resources wisely 81
Slide 117: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® and effectively. Justification for the support of this system suffers when highly disruptive abuses occur. Access to and use of the Internet is a privilege and should be treated as such by all users of this system. The IAB strongly endorses the view of the Division Advisory Panel of the National Science Foundation Division of Network, Communications Research and Infrastructure which, in paraphrase, characterized as unethical and unacceptable any activity which purposely: (a) seeks to gain unauthorized access to the resources of the Internet, (b) disrupts the intended use of the Internet, (c) wastes resources (people, capacity, computer) through such actions, (d) destroys the integrity of computer-based information, or (e) compromises the privacy of users. The Internet exists in the general research milieu. Portions of it continue to be used to support research and experimentation on networking. Because experimentation on the Internet has the potential to affect all of its components and users, researchers have the responsibility to exercise great caution in the conduct of their work. Negligence in the conduct of Internet-wide experiments is both irresponsible and unacceptable. The IAB plans to take whatever actions it can, in concert with federal agencies and other interested parties, to identify and to set up technical and procedural mechanisms to make the Internet more resistant to disruption. Such security, however, may be extremely expensive and may be counterproductive if it inhibits the free flow of information which makes the Internet so valuable. In the final analysis, the health and well-being of the Internet is the responsibility of its users who must, uniformly, guard against abuses which disrupt the system and threaten its long-term viability. Acceptable Use Policy An Acceptable Use Policy is the document in an organization that typically addresses the expectations an organization communicates to its employees, relative to their responsibilities with regard to information security. The Corporate Security Policy may contain the Acceptable Use Policy, but also includes additional policy documents that reflect security policies affecting people, processes, data, technology, and facilities (i.e., physical structures and their surroundings). Examples would be access control policies, afterhours entry into a building and the like. 82
Slide 118: Security Operations and Administration Security Administration: Policies, Standards, and Guidelines Security Policy Implementation “Policies” are a communication of an expectation by an individual or group in authority. They are the “why” security is important and the “what” is expected, relative to responsibilities for information security, of employees, contractors, business partners, vendors, and others. Typically, an acknowledgement that the individual had read, and understands, the policy is required for the policy to be enforceable in the event of prosecution. This acknowledgement can take the form of a written signature on a policy document or it can also be a button that, when clicked, “accepts” the acknowledgement digitally. This type of acknowledgement is widely used for the acceptance of security and privacy policies over the Internet. Components that assist in the creation of an effective policy are: Definitions Purpose Authorizing individual Author/sponsor Scope of the policy Measurement of effectiveness Exception process (only as required; exceptions should be few and far between) • Accountability • Effective/expiration dates • References (policies, procedures, other documentation) • • • • • • • Policies must be distributed, either electronically or manually, to all applicable parties. An acknowledgement of receipt and understanding of the policy must be signed and retained by the organization. Failure to do so opens the organization to liability in the event of a breach of policy. “Procedures” are the detail of “how” to enact the policy. They are the nuts and bolts, step-by-step, in the trenches discussions about how security activities are to be satisfactorily completed by the organization. An example of a security procedure is the step-by-step construction of a hardened intrusion detection system (IDS). “Standards” are governing documents that are widely used (i.e., “standard” use) by all organizations that give hard prescriptions (“requirements”) relative to what is acceptable internationally for information security. An example of such a standard is the ISO 17799, the code of practice for information security, which is used as a guideline for organizations to apply best practices for information security. This guideline becomes a standard when accepted as such by the organization. 83
Slide 119: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® “Guidelines” are actually recommendations, and are not necessarily subject to hard and fast enforcement. Many organizations make the mistake of imposing guidelines rather than policies; this leaves the communication of expectations open to interpretation, thereby opening the organization to potential misinterpretations for which there is no redress. Guidelines are earmarked by the use of the words “should,” “could,” “may,” and such, versus imperative language used in policies, such as the word “must.” Some organizations use the work “guideline” when creating policies. This may create some confusion in the environment; however, the important thing is to clearly and unambiguously communicate expectations surrounding information security to the organization. “Baselines” are used to communicate a current or desired state to which the organization aspires. Good examples of baselines are those provided from vulnerability scanning (e.g., the current state “baseline” of the organization’s technology security involved in the scanning) and “baseline” firewall or network device configurations (e.g., to reflect either current or desired states). While it is the security practitioner’s job to ensure that security activities are completed satisfactorily, it is senior management’s responsibility to ensure that expectations are formally documented and available to all applicable parties. It is also senior management’s responsibility to ensure that all parties understand that information security is a corporate priority and that security requirements will be strictly enforced. Without enforcement, formalized documents are worthless and will actually become an impediment to, rather than promotion of, security within the organization. Implementing Security Requirements Guidance Certification and Accreditation Process Concepts The term “certification” is best defined as the comprehensive analysis of the security features and protective measures of a system to determine how closely the measures meet security requirements. Certification considers the following in the system or product’s operational environment: • • • • • The security mode of operations A list of authorized users and their skill set/training Data sensitivity and criticality, and the applications that handle them Systems and facility locations and configurations Interconnection with other systems Systems Accreditation The practice of “accreditation” can best be described management’s de84
Slide 120: Security Operations and Administration cision to accept risk and operate its certified systems. Of particular interest to accreditation is: • • • • • Security mode in use Countermeasures selected for use Stated threat/vulnerability pairs Interdependence with other systems Stated period of time System Certification Effort Support British Standard (BS) 7799 As stated by Bureau Veritas, the BS7799 standard “addresses information security from the management point of view.” While the BS7799 does contain technical information, the standard is not technical in nature. Management policies and procedures are counted upon to protect the organization from threats to its assets. In 1998, BS7799-2 was produced to promote requirements surrounding an “information security management system” and to promote certification against the standard. Version 2 of the standard was revised on May 15, 1999, and amended again in January 2001. In order to align the standard with ISO9001:2000 and ISO14001:1996, the standard was updated again on September 5, 2002. The BS7799-2 2002 is the current version being used for certification of an organization. This standard, as well as the ISO 17799, will be discussed in a subsequent section in this chapter. ISO 17799 ISO 17799 is based upon the BS7799. The first version of ISO 17799 was published and adopted in December 2000. ISO 17799 is a code of practice standard for information security management that encompasses industry best practices in security through the adoption of a comprehensive set of controls. It is important to note that not all controls listed in the code of practice will be used by every organization. It also states that further guidance may be needed when aligning the organization’s security practices to best practices in the field. That is why it is really a guideline until adapted and adopted by an organization as the standard. ISO 17799 is broken into several categories for consideration: • Scope of the recommendations for information security management within the standard • Terms and definitions • Security Policy • Organizational Security • Asset Classification and Control • Personnel Security • Physical and Environmental Security • Communications and Operations Management 85
Slide 121: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • • • • Access Control Systems Development and Maintenance Business Continuity Management Compliance Sections 3-12 of the standard contain significant additional information relative to controls surrounding people, process, data, technology and facilities. A full version of the standard can be obtained from the British Standards Institution (BSI; www.bsi-global.com) or from Bureau Veritas (www. bureauveritas.com). IPSEC IPSEC is a network protocol standard. The Internet Engineering Task Force (IETF) updated this standard in 1997 and 1998. It addresses security at the Internet Protocol (IP) layer of the network model. Its key goals are authentication and encryption. Components include the IP Authentication Header (AH) and the Encapsulating Security Payload (ESP). Both provide mechanisms for access control. Key management is accomplished using ISAKMP. TEMPEST TEMPEST is an electromagnetic shielding standard established by the U. S. Department of the Defense. It could use fiber to shield transmission lines, but that is only a small part of the shielding process. It is still in effect and utilized. More information can be obtained from governmental sources. Security Administration: Security Control Architecture What Is a Security Control Architecture? A security control architecture is best described as an architecture that is created, implemented, maintained, monitored, and enforced to ensure information systems are protected as stipulated in an organization’s policy base. Equally important is protecting that information at the appropriate confidentiality, integrity and availability levels that meet with the functionality of the organization and the sensitivity/criticality of the data. The following are models present in the security space that assist the organization with the creation of a proper security architecture. Bell–LaPadula Bell–LaPadula is a “confidentiality model.” Bell–LaPadula applies only to confidentiality of information and identifies paths that could lead to inappropriate disclosure. The concept of “secure state” is defined within the model. Secure state refers to the use of access modes and assignment of “subjects to objects,” as such assignment meets the objectives of the organization’s security policy. It also defines modes of access and provides prescriptions for the assignment of access to objects within the organization. Modes of access used in this model include read only, read/write and write only. The simple security 86
Slide 122: Security Operations and Administration conditions of this model surround a subject’s ability to “read up.” That is, a user with a set access level cannot read higher, as no access has been provided at that level. Likewise, a user is not allowed to write lower, as it might be possible to reveal “secret information” (see confidentiality) to users at that lower level. This property is called the “star property.” The “strong star property” dictates that users may only read and write at their access level. Mandatory access control in TCSEC is based on the Bell–LaPadula model. Biba Integrity Model The Biba Integrity Model was the first to address integrity in computer systems. The model is based upon a “hierarchical lattice” of integrity levels. The model’s implementation is the “opposite” of the Bell–LaPadula confidentiality model. The goal of the model is to prevent unauthorized users from making modifications to data. With that goal in mind, the model forbids reading lower (i.e., the reading of objects with “less integrity”) and writing higher, which may affect the integrity of the objects at that level. So, the strict integrity policy states that a user cannot “observe” objects of lesser integrity. The star property for integrity stipulates the prohibition for writing to objects of higher integrity. An additional property in the integrity model is the “invocation property.” That is, a user cannot make a logical request for service to a subject of higher integrity. This prohibition drives to the heart of preservation of accuracy. Clark–Wilson Model Another integrity model, the Clark–Wilson model is the first to address all three integrity goals: • Prevent unauthorized users from making modifications • Prevent authorized users from making improper modifications • Maintain internal and external consistency The model does this through “well-formed” transactions; that is, it ensures internal consistency and allows users to work with data in ways that promotes this internal consistency. It does so by enforcing the “access triple.” A program “middleman” ensures that a subject (the user) cannot directly access the object. This process is achieved through subject-to-program and program-to-object binding. This access triple enforces the first integrity goal as well as separation of duties. Separation of duties enforces the second integrity goal. Non-Interference Model The non-interference model is promoted through segregation; that is, organizations create separate environments (domains) for authorized users so that they cannot interfere in each other’s operations, in violation of the organization’s security policy. Access Control Matrix The access control matrix is a two dimensional matrix for a discretionary access control environment which details the approved mode of access for its users. An access control matrix is created that 87
Slide 123: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.8 History of Relevant Standards matches users to resources in the organization. This method has proven to be a simple way to start an investigation for covert channels within the organization. Information Flow Model The information flow model elaborates how information can flow from one object to another. This is a variation of the access matrix model. Information flow is limited based upon the object’s security properties (sensitivity). Like the access control matrix , the information flow model assists with covert channel analysis. Evaluation Criteria Trusted Computer System Evaluation Criteria Developed under the auspices of the U.S. Department of Defense, the TCSEC has been used by the federal government to “rate” the security properties of a system or computer product. The current version is dated September 26, 1985 (DOD 5200.28-STD). The TCSEC is also referenced as the “Orange Book.” It was developed in the early 1980s and only addressed the issue of confidentiality Additional “booklets” are available for other purposes, such as securing office automation, and are also referred to by color. The publications are collectively referred to as the “Rainbow series.” Goal of TCSEC The main goal for the creation, implementation, and maintenance of the TCSEC was to provide an organization a measurable baseline from which to declare “trust” in the security of automation within the orga88
Slide 124: Security Operations and Administration nization. It also serves to provide guidance for vendors with regard to their provisions for security within their products. TCSEC Classes of Trust TCSEC offers a “rating system” (classes of trust) to apply to the organization’s information systems. The system is detailed below, from least protected to most protected. • Division D — Minimal protection • Division C — Discretionary protection • Class C1 — Discretionary Security Protection. Minimum requirements for C1 include: — Documentation — A security user’s manual, which includes privileges for use and their accompanying functions — Trusted Facilities manual, indicating appropriate control of facilities — Test plans and results — Design documentation, including the protection philosophy of the organization • Class C2 — Controlled access protection. All the requirements for C1 apply, with the following in addition: — Object reuse protection (protection against reuse of storage objects) — Added protection for authorization and audit data (i.e., protected audit trail) — Division B: Mandatory Protection: As opposed to the discretionary access control aligned with C-level ratings, the B-level ratings impose mandatory controls • Class B1 — Labeled security protection: All protections listed in C2 are required, along with the following additional protections: — Mandatory access control and access labeling of all subjects and objects (see Bell–LaPadula) — Data sensitivity label checking (i.e., label integrity) — Auditing of labeled objects — Mandatory access control for all operations — Process isolation in system architecture — Design specification and verification • Class B2 — Structured Protection: All the requirements for a B1 rating are also required for B2, with the following additions: — Program sensitivity labels — Hierarchical device labels — Trusted path communications between the user and system (log on and authentication) — Separate operator and administrator functions — Covert channel analysis • Class B3 — Security Domains: All the requirements for a B2 rating are also required for B3, with the following additions: 89
Slide 125: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® — More granularity surrounding security implementation — Notify security after aggregation of auditable events — Define the role of security administrator — Recover from system or product failure without jeopardizing protection. — Documented procedures to ensure systems and products start and achieve the secure state — Division A: Verified protection • Class A1 — Verified design: All the requirements for a B3 rating are also required for A1, with the following additions: — Formalized protection and evaluation methods are required, as well as definitive proof of the integrity of TCB The security categories delineated by the Department of Defense, above, are based upon the Trusted Computer Base (TCB). TCSEC 1983 defines the TCB as “the totality of protection mechanisms within a computer system, including hardware, firmware, and software, the combination of which is responsible for enforcing a security policy.” Information Technology Evaluation Criteria (ITSEC) ITSEC was published by The United Kingdom, the Netherlands, Germany, and France in May of 1990, based on the Orange Book and existing standards within the countries. It addressed confidentiality, integrity, and availability. Version 1.2 was published in June 1991, after vetting the completed standard to t he international community, by the Commission of the European Communities. ITSEC is used for the purpose of valuation of systems and product security. Evaluation is IT security intensive and results in holistic function and penetration testing. An agreed-upon security target serves as the baseline for assurance that a product or system meets the requisite security specification. Security Target A Security Target is set of prescriptions that provide the baseline for evaluation of a product or system. They must be critically reviewed and determined to represent an appropriate baseline for evaluation; as such, they must be complete, accurate, and consistent. In addition to containing information on the standard against which the product or system will be assessed, it also includes a description of the security goals, as well as the potential threats, present within the organization. Prescriptions include: • • • • Presence of a system security policy Formalized, required security enforcing functions Optional required security mechanisms Claimed rating of minimum strength Target of Evaluation (TOE) The TOE is simply the system to be evaluated. Note that in this definition, a “system” includes the people and documentation associated with it. It is also important to note that components of 90
Slide 126: Security Operations and Administration a system may be evaluated in lieu of a full system review. This could include evaluation of an operating system, a database, a combination of software, and the requisite hardware for its operation, and so on. Comparison of ITSEC to TCSEC As in the TCSEC, the ITSEC classes are hierarchical; that is, each class adds additional requirements to the class prior to it. The specific functionality and mechanisms of the ITSEC are designed to correspond to the TCSEC classes of trust. The ITSEC functional classes correspond to the TCSEC classes of trust as follows: • • • • • • F-C1, E1 = C1 F-C2, E2 = C2 F-B1, E3 = B1 F-B2, E4 = B2 F-B3, E5 = B3 F-B3, E6 = A1 Other ITSEC functionality classes exist that provide prescriptions for high integrity, high availability, high data integrity, high data confidentiality and high demand network transport confidentiality and integrity aspects. ITSEC Assurance Classes ITSEC operates through the use of “assurance classes.” Much like the TCSEC, the ITSEC assurance classes are ascending class rankings that reflect the level of confidence (i.e., assurance) that can be place in the target of evaluation’s security functionality. Each class also points to the rigor with which the evaluation is conducted. The ITSEC Assurance Classes are detailed below. • E0 — Inadequate assurance is present (failed to meet E1). • E1 — A security target and informal description of the target of evaluation’s architectural design must be produced. Functional testing satisfies the target. • E2 — In addition to E1 requirements, an informal description of the detailed design and test documentation must be produced. There must also be an approved distribution procedure and configuration control present. • E3 — In addition to E2 requirements, source code or hardware drawings must be produced. Evidence of testing of security mechanisms must also be produced. • E4 — In addition to E3 requirements, a formal model of the security policy and a semiformal specification of security enforcing functions, architecture and design must be produced. • E5 — In addition to E4 requirements, the detailed architectural design shows close correlation to the source code and drawings. • E6 — In addition to the E5 requirements, a formal description of the architecture and the security enforcing functions is to be produced; these must be consistent with the security policy model produced in E4. 91
Slide 127: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.9 Roadmap to the Common Criteria Common Criteria: ISO 15408 The Common Criteria Version 2 (CC) is the culmination of the aggregation of standards from the United States (TCSEC, “Orange Book”), Canada (Canadian Trusted Computer Product Evaluation Criteria (1993)), and Europe (ITSEC), the purpose of which is to provide a unified prescription for the conducting appropriate and meaningful security product evaluation activities. The Common Criteria is composed of numerous security functional requirements that the approving bodies believe represent the current best practice for trusted products and systems. The actual security assessment considers these requirements to develop a protection profile for the target of evaluation. In addition, an appropriate security target, to be used for comparisons, can also be developed from these requirements. If the assessment is being conducted to evaluate more specialized aspects of the target system, the requirements can be combined to facilitate. Much like the ITSEC, the Common Criteria evaluation is conducted by creating comparisons against standard assurance levels, termed “Evaluation Assurance Levels (EAL0 to EAL7).” Like the TCSEC and ITSEC, the Common Criteria assurance levels are ascending class rankings that reflect the level of confidence (i.e., assurance) that can be place in the target of evaluation’s security functionality. Each level also points to the rigor with which the evaluation is conducted. A roadmap for the Common Criteria is presented Figure 2.9 (part 1), Figure 2.10 (part 2), and Figure 2.11 (part 3). The relationships among the components of the Common Criteria, and their use in evaluation, are diagrammed in Figure 2.12 and Figure 2.13. 92
Slide 128: Security Operations and Administration © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.10 Roadmap to the Common Criteria (part 2) Security Best Practices Implementation Basic Security Mechanisms Least Privilege The concept of least privilege dictates that personnel are only given the minimum necessary access rights and permissions to complete their required job functions. Least privilege is one of the guiding tenets of information security. © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.11 Roadmap to the Common Criteria (part 3) 93
Slide 129: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.12 Common Criteria Evaluation Relationships Separation of Duties Separation of duties may best be described as denying the opportunity for one individual to “hold all the keys to the kingdom.” That is, separation of duties ensures that one person is not responsible for initiating and authorizing a sensitive transaction. Consider the example of initiating and authorizing a payment. If there were no separation of duties between these two functions, an individual could potentially both initiate and approve a payment to him or herself. This places an organization’s assets in jeopardy for fraud. Control for this situation can be implemented by either enforcing the fact that an initiator cannot also be an authorizer of the same transaction (i.e., tied to role, which is an example of “dynamic” separation of duties) or by ensuring that initiators and not also authorizers in any case (i.e., an example of “static” separation of duties). Rotation of Duties Rotation is a way to provide both cross-training for employees or contractors, and to also allow for following up or verifying the employee’s or contractor’s actions relative to the handling of the organization’s assets. Rotation is usually based on a role, a time frame, or both. Rotation of duties can also be used to break up collusion designed to avoid the security objectives of separation of duties. Mandatory Vacation Another mechanism that can be used by the organization to verify and validate employer or contractor activities is to ensure that all individuals within an organization be required to take a mandatory vacation of one week or longer. This allows for another employee or contractor within the organization to perform the vacationing employee’s job duties and to potentially verify work performed by this individual and detect potential fraud. 94
Slide 130: Security Operations and Administration © Copyright (ISC)2 ® Inc. All Rights Reserved. Figure 2.13 Common Criteria Evaluation Relationships (continued) Sample Questions 1. What is “integrity?” a. The assurance that data stored, processed and transmitted has not been modified or destroyed in an inappropriate manner, either inadvertently or maliciously, from its original and correct state b. The assurance that resources can be successfully accessed by authorized users when they are needed c. The assurance that data is kept private, restricted only to authorized individuals d. None of the above What is the A-I-C Triad? a. The security triad b. The risk management triad c. The infrastructure triad d. All of the above What is least privilege? a. Access to all an organization’s resources b. Access to sensitive resources only c. Access to those resources required to perform a job function d. All of the above e. A and B only f. B and C only 2. 3. 95
Slide 131: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® 4. How can least privilege be maintained? a. By verifying a user’s role in the organization b. By verifying the minimal set of data that is required for successful completion of tasks for this role c. By verifying the data’s location d. All of the above What is “accountability?” a. Evaluation of the rights minimally necessary to perform required business functions b. The ability to tie an activity to the individual or system that initiated it, with 100% certainty c. The granting of permissions, by a data owner, and the enforcement of those permissions d. None of the above What does a risk assessment evaluate? a. Threats b. Errors c. Vulnerabilities d. A and B only e. B and C only f. A and C only g. All of the above What are the types of risk assessment? a. Qualitative b. Quantitative c. Hybrid (both qualitative and quantitative) d. All of the above How can an organization address risk? a. Transfer b. Accept c. Avoid d. Mitigate e. All of the above Software development models include: a. The Waterfall Method b. The Scientific Method c. The Microsoft Method d. None of the above Spiral Model steps include: a. Review and edit 5. 6. 7. 8. 9. 10. 96
Slide 132: Security Operations and Administration b. Risk management c. Engineering and production d. None of the above 11. ISO 17799 represents: a. A standard for security risk assessment b. A standard for information security management systems c. A code of practice for information security d. All of the above Bell–LaPadula is an example of a: a. Security model b. Confidentiality model c. Authentication model d. Authorization model TCSEC is also referenced as: a. The Yellow Book b. The Purple Book c. The Blue Book d. The Orange Book Services provided by the operating system include: a. Error detection b. Controlled access to files c. Accounting functions d. All of the above e. None of the above The data classification for the most sensitive of data within an organization is labeled: a. Confidential b. Internal Use Only c. Restricted d. Public e. None of the above 12. 13. 14. 15. 97
Slide 134: Domain 3 Analysis and Monitoring Eric Waxvik Analysis and monitoring play key roles in the security life cycle. Without an analysis, one can neither determine whether policies are correct and cover an organization’s range of needs, nor whether procedures are correct (and if they are, are they being followed properly? Are the organization’s network and authentication systems designed correctly and functioning properly? Is the incident response team properly trained and following procedures?) This chapter explains what an analysis by audit is and why we need one, how to conduct an audit, various levels of testing, and the important aspects of monitoring. Section 1: Security Auditing Security Auditing Overview This chapter addresses the issues IT security practitioners must prepare to face regarding audits of the organization’s security framework (whether performed by internal or external parties). The security framework, discussed in detail in the next section, is comprised of the policies that govern organizational security as well as the tactical controls (standards, procedures, baselines, and guidelines) put in place to carry out and support the policies. The main question answered in this section is: “What do auditors check for, and why, when performing IT security assurance services for an organization?” By understanding these issues, the IT security practitioner can be proactive in improving and maintaining system security so as to not only pass audits, but more importantly, to safeguard the systems and data for which the IT security practitioner is responsible. IT security practitioners should aim to see past the audit itself and do the best possible day-to-day job of preparing their systems for maximum confidentiality, integrity, and availability. 99
Slide 135: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® At a high level, auditors check for the following: • The existence of sound security policies appropriate for their business or activity • The existence of controls supporting the policies • The effective implementation and upkeep of the controls IT security practitioners are advised to know the benchmark standard to which they will be held accountable. What Are Security Audits? A security audit is an organized, independent technical assessment that measures how well an organization employs strategic security policies and tactical security controls for the purpose of protecting its information assets. Audits may also be part of a regulatory control by government or oversight organization or be part of a certification for a partnership program. Activities performed by auditors seek to establish assurance that the organization has identified and managed all risks through the implementation of controls and other assurance mechanisms. Trust, or assurance, is gained when the management of an organization is confident that the controls are effective to mitigate risk to acceptable levels. This means that the systems supporting a security framework are in place and working properly. Auditing is a comprehensive process that can cover a very large or very small scope. Because it is a snapshot in time, audit studies can be used to gauge either the progress or the decline of an organization’s security profile over time by comparing similar audits. Auditors can audit the effectiveness of many technology solutions: • • • • • • • • • • • • • • • • High-level security policy Security standards effectiveness Processes and procedures Application security Firewalls Anti-virus software Password policies Intrusion detection and event monitoring systems System hardening policies Access control Change control processes for configuration management Media protection (backup tape storage) Cryptographic controls Contingency planning Hardware and software maintenance Physical security 100
Slide 136: Analysis and Monitoring Why Are Security Audits Performed? Audits are performed for the following reasons: • Iterative policy improvement — an audit plays a key role in policy improvement. The process is to create a policy, implement the policy, audit effectiveness of the policy, and rework policy (audits do not make or implement policy and most auditors would be very hesitant to be too involved in this, as it would impair their independence; it would be better stated that audits may initiate policy improvements or are part of the natural policy life-cycle). That is not to say audits cannot comment on why they reported what they found, the way they found it, and give an example of something different — it is a fine line for the auditor to walk. • Policy adherence — an audit will help to verify adherence to or variance from organizational security policies which are written to mandate organizational asset protection. • Policy effectiveness — the fact that an organization has a security policy does not mean that it is necessarily comprehensive or effective. The effectiveness should focus on whether the control addresses the associated risk. The control is effective when it reduces the risk to an acceptable level without impeding business operations unnecessarily. Auditors must address gaps in policy because an effective policy must also address all of the issues and potential issues. An auditor should be able to highlight those gaps in policy. • Regulation adherence — verifies adherence to mandated governmental laws and regulations that may apply to an organization’s situation. • Mitigation ranking — an audit is used to rank systems based on the seriousness of identified vulnerabilities and system criticality for the purpose of providing an overall ranking of their importance for mitigation activities. Highly ranked mitigation candidates are often a result of mission critical systems that have high vulnerabilities. Systems that have vulnerabilities that are a lower potential impact and are not as critical to mission and operation of an organization will probably be ranked lower in the mitigation system rankings. • Corporate merger or takeover — an audit would be used to understand the status of the infrastructure, to ensure the organizations are compatible or are as described in documentation. • After-action — an audit can also be used to find out what steps were missed and why and how to fix them. Security policies should be pursuant to supporting the principles of due care, that is, taking prudent steps to protect the organization from anticipated events that could lead to compromise of confidentiality, integrity, and/or availability. Audits, therefore, are performed to demonstrate the following: 101
Slide 137: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • Managerial due care responsibility — has management taken all of the actions and performed due diligence for the organization? Hiring one person to be the security department of a large multinational organization might not be considered due diligence. • Corporate accountability — has the corporation or organization put in place the guidelines and standards necessary? • Individual accountability — has each person in the structure done his job and kept up with the standards and policies required by his job description? Defining the Audit Benchmark Auditors determine whether systems are compliant to a standard defined by the organization, as well as the adequacy of that standard. Without a standard, auditing would become too subjective, and issues deemed important to one group of auditors may be overlooked by other auditors (depending on the methodology they use to perform the audit). There will always be a need for a special review or audit so this benchmark attempts to give a more consistent baseline. Audit methodologies might use one of the following certification guidelines (which are discussed in the next section): • British Standard BS 7799-2:2002 • NIST SP 800-37 (still in draft form), “Guidelines for the Security Certification and Accreditation of Federal Information Technology Systems,” which can be retrofitted for private industry • Cobit (Control Objectives for Information and related Technology) TM from the Information Systems Audit and Control Association (ISACA) TM • An amalgam of these guidelines • Another guideline deemed appropriate – borrowed from other corporations or Web sites • A process developed in-house Note that ISO 17799 is not a standard against which one can certify a security framework. This is discussed more extensively in the next section. While people may discuss the merits of one standard or another, it is more important to have a baseline for your audit that accomplishes your objectives. Audit Participant’s Role Auditors and IT security practitioners are participants in audits. Auditors ask questions and collect information. IT personnel may assist in the collection and interpretation of this information because they know their systems best. While using the IT personnel maybe helpful, they also might be the reason for the audit. It is always important for the auditor to examine why the audit is taking place. Later, the data is analyzed and compared to good practice standards. 102
Slide 138: Analysis and Monitoring An auditor of IT security systems has several principle responsibilities, including: • Providing independent assurance to management that security systems are effective • Analyzing the appropriateness of organizational security objectives • Analyzing the appropriateness of policies, standards, baselines, procedures, and guidelines that support security objectives • Analyzing the effectiveness of the controls that support security policies • Stating and explaining the scope of the systems to be audited • Limiting the audit (in some cases) if the act of the audit will affect critical applications or business IT security practitioners are often called upon to directly interface with auditors. Security practitioners collect system information for the purpose of gauging compliance with the chosen standard, baseline, and procedures. Auditors are not the enemy. By maintaining a professional relationship with them you can learn what is important to them and hopefully they can learn from you as well. This type of two-way professional relationship contributes to a more secure organization. Keep in mind that auditors often have access to high-level management and can help you bring previously ignored, pressing problems to the foreground. Auditors can back up the opinions of front line IT personnel so that budget funds can be allocated and action taken. Defining the Audit Scope One way to define the scope of an audit is to break it down into seven domains of security responsibility; that is, to break up the IT systems into manageable areas upon which audits may be based. These seven domains are: • User Domain — the users themselves and their authentication methods • Workstation Domain — often considered the end user systems • System/Application Domain — applications that you run on your network, such as e-mail, database, and Web applications • LAN Domain — equipment required to create the internal LAN • LAN-to-WAN Domain — The transition area between your firewall and the WAN, often where your DMZ resides • WAN Domain — usually defined as things outside of your firewall • Remote Access Domain — how remote or traveling users access your network The scope of the system to be audited, including the following procedures, defines how large the audit will be: 103
Slide 139: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • Analyzing critical servers for vulnerabilities, including unapplied patches and unnecessary services within the LAN Domain • Analyzing external Internet servers for vulnerabilities using vulnerability assessment testing techniques • Analyzing firewalls for unnecessary services and misconfiguration in comparison to the security policy in the LAN-to-WAN Domain • Reviewing the business continuity plan for one or more domains • Comparing high-level security policy against industry good practice • Analyzing the access controls on key business systems in the System/ Application Domain • Analyzing applications (like Web servers) in the System/Application Domain for tightness of controls • Analyzing remote access systems for 2-factor authentication effectiveness in the Remote Access Domain The audit scope will define a boundary to the audit, such as whether interconnected systems will be reviewed or whether this audit will be detailed and thorough or high level. The scope will be subject to change if an immediate, serious vulnerability is detected. Defining the Audit Plan Projects require planning; otherwise, valuable time and resources are wasted. An audit plan is no different. Therefore, when approaching and planning an audit, make sure you know the steps involved. The following list details some of these steps to consider when formulating a plan: • Understand the scope — an auditor should know what he is being asked to audit and how long he has to perform the audit. • Understand the intended results — an auditor needs to know the overall goal of the audit. • Understand the personnel resources — an auditor will need to know which personnel on his own team and on the organization being audited will be involved. These people help gather and synthesize information and move the audit along. • Review previous audits — an auditor may wish to review previous similar audit results to become familiar with past issues. Some auditors, however, may not want to be prejudiced by previous conclusions. • Conduct a site survey — an auditor will want to understand the environment and the interconnections with other systems. • Review documentation — an auditor will want to review system documentation and configurations. • Review host logs — an auditor may ask to examine system logs. • Review incident logs — an auditor may ask to review security incident logs to get a feel for problem trends. • Review risk analysis output — an auditor will want to understand sys104
Slide 140: Analysis and Monitoring tem criticality ratings that are a product of risk analysis studies. This helps rank systems for mitigation in the reporting phase. Review policy — an auditor will want to understand the policies that pertain to a system. Review how are systems updated. Review the change control process. Review how the organization allows access. Review how data is classified. Perform hands-on analysis — an auditor may want to review the system to see first hand how it is setup. Or perform a vulnerability analysis scan on the network and/or host components with specialized software tools to gain that perspective as well. Gather information — one form is questionnaires — an auditor may want to construct questionnaires that query individuals in the IT organization about how they perform their jobs. • • • • • • • Audit Data Collection Methods Audit data collection methods include: • Questionnaires — questionnaires provide insight into attitudes and processes performed by IT personnel. • Interviews — interviews are a chance to initiate face-to-face dialogue with stakeholders, system owners, and system operators. • Observation — observation of processes can provide insight into operations. • Checklists — checklists allow for orderly and thorough collection of audit data. • Reviewing documentation — documentation, if it exists (and is a copy off-site) provides insight as to why a system is set up the way it is. Outdated or poorly written documentation is often a sign of risk to a system. • Reviewing configurations — configurations provide raw information about how software components are interlinked to form the system. • Reviewing policy — reviewing policy is a way to discover how the organization deploys technology and provides a written record to which industry “good” practices can be compared. Policy must also be aligned with the strategic business mission of the organization. • Performing security testing (vulnerability analysis) — security testing, as described later, allows for the collection of potential vulnerability information. • Review your disaster recovery procedures for both physical and network based events. Post Audit Activities • Exit Interviews — After an audit is performed, an exit interview will alert personnel to glaring issues they need to be concerned about immediately. Besides these preliminary alerts, an auditor should avoid 105
Slide 141: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® giving detailed verbal assessments, which may falsely set the expectation level of the organization with regard to security preparedness in the audited scope. Analyze Data — An auditor will likely perform data analysis and synthesis away from the organizational site. This stage allows the auditor to review everything learned and present her observations in a standard reporting format. Produce Audit Findings — An auditor will produce audit findings for presentation to the organization. Findings are often listed by level of compliance to the standard benchmark. The comparison of audit findings to stated policy or industry “good” practices produces a picture of what must be improved. Often findings include recommendations for mitigation or correction of documented risks or instances of noncompliance based upon system criticality. An audit report often begins with an executive summary followed by detailed information. Present audit findings — Audit findings and the audit report are often presented to management. The findings may lead to mitigation activities based on an available budget. • • • • • • • Security Framework An organizational Security Framework is often based upon international and national standards and guidelines. Organizations often take these guidelines and create standards specific to their situation. A well-implemented framework forms the basis for a secure state. An organization can be said to be in a secure state when it is conforming to its stated policy. An organization’s security framework is comprised of the following: • Organizational policies delineate the role of security in the organization. It is a formal statement by top-level management that security is important to the organization and its related activities will be supported financially and otherwise. They are often broad and will describe how a security framework will work within the organization, what individuals or groups within the organization will have responsibility for it, how the policies will be enforced, how they will be checked for compliance, and define the ramifications for noncompliance. • The development of functional policies that succinctly describe how organizational assets are to be used and protected. — Functional issue-centric (acceptable use, e-mail use, remote access, extranet connection, etc.) — Functional issue-centric policies usually deal with the security of processes or activities. For example, an acceptable use policy will state that the Internet is to be used for 106
Slide 142: Analysis and Monitoring business during business hours and that visiting Web sites for political activism, gambling, violence, pornography, etc. is not allowed. — Functional system-centric (anti-virus, server building procedure, firewall rules, IDS monitoring, etc.) — Functional system-centric policies usually deal with technology controls like, for example, how intrusion detection and firewalls are to be deployed, how access control is to be applied to hosts, what access controls should be placed on key network resources, how anti-virus is to be deployed and kept up to date, etc. • The development of the supporting mechanisms to support the policies — Standards — Standards are compulsory component technologies (specific hardware and software products deployed in certain ways) to be used. They may define server, router, firewall, anti-virus software manufactures, and operating system versions based on what that system will be used for. — Baselines — Baselines define minimum required parameters to achieve a consistent security level for a system or business process. For example, a policy may define the anti-virus baseline to be, “the business unit shall update anti-virus definitions on file servers every Monday and Thursday.” They may define how standard goods should be deployed and kept up to date. — Procedures — Procedures define actions to implement standards and baselines. They are step-by-step definitions of how to implement security technologies in the environment. For example, how the firewall is to be configured, how security desk check-in procedures should operate, how tape backups must occur. — Guidelines — Guidelines are recommendations for improving security; however, policy does not define them as being required, leaving implementation and interpretation up to the organization. For example, a policy may define a good anti-virus guideline to be “the business unit should check for new anti-virus definitions on a daily basis and install them if available.” This implies that they are not required to do this but that it is a good idea. The baseline (see above) defines compulsory updates on Mondays and Thursdays. Why Have a Security Framework? Organizations have a responsibility to exercise “due care” in their daily operations. When they do not exercise due care, they can be liable for negligence. There is also the potential for legal action and criminal and/or financial penalties. Due care includes the following descriptors: • The organization takes risk reduction seriously and takes responsibility for it. • The organization is proactive about reducing risk to employees. 107
Slide 143: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • The organization is proactive about reducing risk to organizational assets. • The organization periodically tests its risk reduction processes through auditing. Developing and maintaining an effective security framework reduces risk and demonstrates due care. Security Framework Guidelines and Standards The terms “standard” and “guideline” are often used loosely and interchangeably. This is incorrect and it is important to know the difference. Earlier we defined a security standard to be something that succinctly specifies compulsory component technologies used for security. We then defined guidelines as suggested yet nonrequired security practices. Both of these definitions are in the context of how an organization builds a security framework. Keeping that thought in mind, recognize that the terms “standard” and “guideline” are also often used in the context of practices defined to ensure compliance with a set of rules as defined by a standards body or regulatory body. For example, ISO 9001 is an international “standard” for quality from a recognized standards body (the International Organization for Standards) and some organizations engineer their internal processes to comply with this standard. This being said, you should recognize that a security standard (“you must use brand XYZ intrusion detection system”) is different from a policy development organization standard which attempts to encompass many facets of important issues. Organizations will often incorporate the security guidelines and standards published by policy development organizations (or regulatory bodies that dictate requirements) for the purpose of standardizing their security framework to harmonize with “accepted” or required practices. Good security practice from policy organizations varies widely from general advice on how to implement secure systems (guidelines) to compulsory requirements against which systems may be certified (standards). Unlike ISO 9001, a widely accepted quality standard, there currently is no international consensus as to which security “standard” is the security standard. As a result, organizations use various standards as will be covered later. The standard that is used as a template is often a matter of preference. The system audit activity is performed to compare an organization’s defined policy to the actual system state. It should be performed against a chosen standard to identify where systems are deficient. It is not uncommon to find organizations that modify published standards and guidelines for their own purposes and audit against that definition. Often one of the roles of an IT security practitioner is to ensure that system components adhere to the organization’s chosen standard. The main idea behind meeting a standard is that your organization has demonstrated a level of assurance 108
Slide 144: Analysis and Monitoring that its systems are secure, thus management and other organizations may take confidence in them. Policy organizations and regulatory bodies publish a wide variety of standards and guidelines and are often criticized for making broad statements but imparting little detail about how to accomplish the requirement. Policy development organizations may issue the following to convey a best practice: • Technical reports — often seen as suggested guidelines for secure systems and might be broadly interpreted. For example, the ISO reports (Guidelines for the Management of IT Security) are just that — reports (not standards). They are suggested guidelines. • Technical standards — a standard includes required (compulsory) items. If you do not meet the requirements, then you do not meet the standard. Policy Organization Guidelines Guidelines for good security practice come from several organizations and are often adapted by other organizations to form their own security frameworks. They include the following: • International Organization for Standards — ISO 17799 (now 27001) — A high-level security guideline (often referred to as a standard) not meant for the certification of systems but for high-level security framework assistance. It was passed as a standard late in 2000 (based on British Standard 7799-1). It is a management standard that deals with an examination of the nontechnical issues relating to installed security systems within organizations. — ISO GMITS — A five-part technical report guideline currently in revision that discusses many facets of security frameworks. • Governmental Bodies • British Standards Institute — BS 7799 Part 1 — A high-level checklist oriented security guideline — BS 7799 Part 2:2002 — A standard against which a system may be certified because it uses a lot of “the organization shall do . . .,” words. It has fewer implementation suggestions than Part 1. An organization may be accredited as complying with the BS7799-2. — U.S. National Institute for Standards and Technology. — NIST special publications 800-12, 800-14, 800-26, 800-30, 800-37, and others provide a wealth of strategic and tactical information for developing, running, and certifying security frameworks. • Audit Organizations — Information Systems Audit and Control Association (ISACA).™ — Developers of Control Objectives for Information and Related Technology (COBIT)™ — generally applicable and accepted standards for good IT security and control practices. Their goal is to provide 109
Slide 145: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® a reference framework for management, users, IT auditors, and IT security practitioners. • Professional Organizations — American National Standards Institute (ANSI) — U.S. liaison committees to ISO committees. — Technical Committee T4 participates in the standardization of generic methods for information technology security. — Information Systems Security Association (ISSA). • The generally accepted information security principles (GAISP), when completed, aim to be a comprehensive hierarchy of guidance to provide a globally consistent, practical framework for information security. It is based on the ISO 17799 framework but adds specific prescriptions about how to meet the high-level objectives while not naming specific products. • Computer Emergency Response Team (CERT) — A variety of advice on secure computing practices and incident response techniques is offered. Guideline Summary: • There are competing guidelines and standards for security. No one guideline or standard leads at this time. • Oftentimes guidelines are confused for standards and vice versa. Guidelines are suggested ways to do something whereas standards are compulsory. • If an organization modifies a standard for its own purposes, can others still take confidence in their systems? This is subjective but what is important is that the organization follows reasonable practices. You can always use a required baseline and expand on it versus modifying the required baseline thereby maintaining the integrity of the standard for trust purposes but making sure that it fits your overall needs. • What is the importance of the guidelines that you are following and why are you following them? There are different standards and guidelines for different ways of doing business. Security Controls After the planning and implementation of the security framework (based upon any number of standards and guidelines), IT security practitioners are often the ones responsible for day-to-day operations. If the security framework is executed in an informed way, that is, with comprehensive policies that drive environmentally appropriate baseline security definitions implemented with effective procedures, the system should be in a reasonably secure state. 110
Slide 146: Analysis and Monitoring Periodically auditing the security framework is part of due care and helps ensure that the framework is maintained. Auditing helps to spot what needs to be improved to get back to a more secure state by doing the following: • • • • • • • Uncovering vulnerabilities Uncovering deficient operations Uncovering insecure system changes Changes due to management influences Changes due to technology Changes due to business plan or model Changes in standards In the next section, we will show the IT security practitioner what types of issues she may be challenged with by an auditor. Security Controls Security controls are activities, processes, or technologies that are implemented to reduce the risk of a security event from adversely affecting the organization. Controls fall into three broad categories: • Administrative Controls — centered on protecting the organization’s overall mission and reducing the risk of asset loss. They tend to be fairly high-level (“managerial”) in nature. These controls tend to be more process-, procedures-, and goal-oriented. • Physical Controls — centered on improving operational deficiencies that could be exploited by threat sources. Physical controls are generally carried out by people using well documented procedures. These controls tend to help focus on the physical aspect — what people can touch. • Technical Controls — centered on reducing risk by implementing specific technologies or technical processes. Technical controls are generally carried out by computers (after being deployed by people) using documented processes and procedures. Technical controls are often referred to as logical controls. These controls tend to focus more on automated systems and processes. Security controls are the security framework items that are intended to reduce risk for the organization. Administrative Controls Administrative controls tend to be fairly highlevel (“managerial”) in nature and do not deal with minute system details. The following are some security management control examples: • Senior-level security statement, direction, support, and assignment of responsibility • Conducting risk management activities for the reduction of risk • Conducting periodic audits of security controls • Security policies • The security organization’s plans for system security 111
Slide 147: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® • Personnel controls like separation of duties, granting and terminating user computer access, background checks, duty rotation • Business continuity planning in case of disaster • Incident response policies — detecting, reporting, and responding to incidents • System documentation and maintenance thereof • Security awareness training for organizational staff • Data labeling to control the flow of sensitive data to unauthorized users • Media disposal including paper and magnetically stored data • Timely security reporting to allow for knowledge of system activities and to allow for incident response capability Physical Controls It is important to have good physical controls because most of your IT devices are inherently weak if you have direct physical access to them. Good physical controls are also important for the safety of your personnel, property and your intellectual property. The following are some security operational control examples: • Physical security including guards, CCTV, alarms, fences, locks • Environmental security including fire detection, fire suppression, system cooling, emergency power • Access security including visitor procedures, badges, biometrics, securing data centers, wiring closets • Mobile system security including laptop locking cables, PDA security, hard drive encryption Technical Controls Technical controls can reduce risk by implementing specific technologies or technical processes. Technical controls are generally carried out by computers but are implemented and maintained by IT security practitioners. The following are examples of technical security control: • • • • • • • • • • • • Firewalls Host intrusion detection Network intrusion detection Anti-virus (malicious code) detection for workstations and hosts Access control lists Logging and logging analysis for event alerts Standard patch alerting and deployment Encryption standards Host hardening Remote access Wireless deployments Mobile deployments 112
Slide 148: Analysis and Monitoring Control Checks — Identification and Authorization An audit can provide a way to critique the effectiveness of identification and authorization systems. Sample audit questions include: • Who approves authorized users and how is access privilege determined? • How are users identified and authenticated? • What is the password policy for your systems and how is it enforced? • Are there controls in place that monitor for unauthorized access attempts? • Do workstations use password protected screensavers? • Do remote access systems utilize multifactor authentication in order to more succinctly identify that the person logging on is who they say they are? Control Checks — User Access Control Access control restricts access of operating system source files, configuration files, and their directories to authorized administrators. Sample audit questions include: • How is access privilege applied (by user, group, or other method)? • What is the change control process for granting access? Who approves it? Who performs it? Is there separation of duty? • Who decides who has access to what and by what method? Is it the creator of the information? • Who implements the policy? • Is access privilege periodically revisited by data owners? • Are decisions for access control documented as they are modified? Control Checks — Network Access Control (Firewalls and Filtering) Implement firewalls in accordance with organizational standards and baselines. Firewall implementation rules should support policy that defines what types of traffic are allowed and disallowed. Implement network access control at security domain borders: • • • • Internet Business unit (i.e., marketing, sales, engineering) Business partner (extranet) Demilitarized Zone (DMZ; the place where customer facing applications are usually kept) Policy-based network access controls (firewalls coupled with filtering routers) are generally deployed between security domains such that unnecessary services are disallowed from domain A to domain B and from domain B to domain A (inbound and outbound). Often organizations have open rules going outbound which leaves them open to attacks that originate from the inside going out. Thus, be sure to define stringent policy-based rules for outbound traffic too. Packet filtering can assist firewalls by preprocessing and dropping generally disallowed services. 113
Slide 149: OFFICIAL (ISC)2® GUIDE TO THE SSCP® CBK® Firewall and Filtering Systems sample audit questions include: • Does the business unit implement firewalls in accordance with the organizational standard? • Are firewalls deployed at security domain interfaces such as Internet access points, business partner network interfaces, and internal highsecurity segments? • Is packet filtering by routing devices performed at security domain interfaces? Is packet filtering necessary at the routers? Are these actions to be logged? Are they being sent securely to a central processing location? • Do the firewall rules match the intent of the security policy? • When rule changes are necessary, what is the nature of the change control process? • Do firewalls control traffic inbound and outbound? • Are firewalls periodically tested for vulnerabilities and adherence to policy? • What mechanism is in place for manufacturer notifications pertaining to patches as they become available? • Is there a method for collecting and analyzing firewall logging event alerts? • How are new firewall upgrades/patches tested to ensure security and continuity of operations? Control Checks — Intrusion Detection and Intrusion Prevention Implement intrusion detection (IDS) or intrusion prevention (IPS) in accordance with organizational standards and baselines. IDS should be designed to alert on disallowed traffic and transactions that are contained within permissible traffic allowed by firewalls or network filters. IPS should be designed to alert and act on disallowed traffic and transactions. See the SSCP Analysis and Monitoring domain section (Security Monitoring) for more information. IDS and IPS sample audit questions include: • Is network-based IDS/IPS deployed on key network segments (server segments, segments that receive or send data traffic from one security domain to the next) so as to detect malicious code or inappropriate activity contained within permissible data channels? • Is host-based IDS deployed on key hosts so as to detect and stop transactions that may compromise the host? Are file integrity processes deployed on key hosts (integrity checking tools)? • Have the IDS/IPS systems been tuned appropriately for the environment? • Do the IDS/IPS rules match the intent of the security policy? • When IDS/IPS changes are necessary, what is the nature of the change control process? 114
Slide 150: Analysis and Monitoring • What mechanism is in place for manufacturer notifications pertaining to patches and signature updates as they become available? • Is there a method for collecting and analyzing event alerts? • Is there a method for incident alerts and responding to those incidents? • Does the IPS fail open? Control Checks — Host Isolation Implement host isolation in accordance with organizational standards and baselines. Isolation is meant to provide protection for internal systems from hosts that interact with untrusted networks. Isolate publicly accessible systems sample audit questions include: • Are publicly accessible systems such as e-mail, Web, and other hosts that service data requests isolated from the Internet as well as your internal networks? • Do you utilize firewall demilitarized zones (DMZ) to isolate publicly accessible hosts? • Is your firewall configured to restrict traffic down to only that which is needed for the systems to do their job? • Do you utilize host-based and network-based IDS for isolated systems? • Do you scan incoming data to isolated systems for viruses? • Are unnecessary and insecure services disabled? Examples of stringent DMZ host communication rules include: • DMZ Web host accepts TCP port 80 (HTTP) from the Internet. No other incoming ports on TCP or any other protocol are allowed by the firewall. • DMZ Web host cannot initiate any connections to the Internet but responses to previously initiated sessions are allowed. Web host should never need to initiate connections to the Internet but must be able to respond. • DMZ Web host can initiate TCP port 1433 (SQL) connections to the trusted network’s internal Web data host for the purpose of fetching or putting data originally requested by an Internet user via HTTP. Additional suggested measures include: • Implement Host IDS on the hosts — guards against internal processes performing actions that should not be allowed like the Web server process accessing data that it normally should not have access to. • Implement Network IDS on the DMZ and the trusted network — alerts to network misuse which are attempts to use permissible data channels (in this case, HTTP and SQL) for disallowed activities. Control Checks — Monitoring Implement monitoring in accordance with organizational standards and baselines. Monitoring should be designed to 115