- Author / Uploaded
- Chris Jackson
Network Security Auditing
Chris Jackson, CCIE No. 6256Cisco Press Cisco Press 800 East 96th Street Indianapolis, IN 46240 ii Chris Jackson,
6,501 1,058 11MB
Pages 514 Page size 252 x 312.84 pts Year 2010
Recommend Papers
File loading please wait...
Citation preview
Network Security Auditing Chris Jackson, CCIE No. 6256Cisco Press
Cisco Press 800 East 96th Street Indianapolis, IN 46240
ii
Network Security Auditing
Network Security Auditing Chris Jackson, CCIE No. 6256 Copyright © 2010 Cisco Systems, Inc. Published by: Cisco Press 800 East 96th Street Indianapolis, IN 46240 USA All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review. ISBN-13: 978-1-58705-352-8 ISBN-10: 1-58705-352-7 Printed in the United States of America First Printing June 2010 Library of Congress Cataloging-in-Publication Data: Library of Congress Cataloging-in-Publication data is on file.
Warning and Disclaimer This book is designed to provide information about Cisco network security. Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information is provided on an “as is” basis. The author, Cisco Press, and Cisco Systems, Inc. shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the discs or programs that may accompany it. The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc.
iii
Trademark Acknowledgments All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. Corporate and Government Sales The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales 1-800-382-3419 [email protected] For sales outside the United States please contact: International Sales [email protected]
Feedback Information At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members from the professional technical community. Readers’ feedback is a natural continuation of this process. If you have any comments regarding how we could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us through e-mail at [email protected]. Please make sure to include the book title and ISBN in your message. We greatly appreciate your assistance. Publisher: Paul Boger
Cisco Representative: Erik Ullanderson
Associate Publisher: Dave Dusthimer
Cisco Press Program Manager: Anand Sundaram
Executive Editor: Brett Bartow
Technical Editors: Todd Reagan, Brian Sak
Managing Editor: Sandra Schroeder
Senior Development Editor: Kimberley Debus
Project Editor: Deadline Driven Publishing
Copy Editor: Deadline Driven Publishing
Editorial Assistant: Vanessa Evans
Book Designer: Louisa Adair
Composition: Mark Shirar
Indexer: Ginny Munroe
Americas Headquarters Cisco Systems, Inc. San Jose, CA
Asia Pacific Headquarters Cisco Systems (USA) Pte. Ltd. Singapore
Europe Headquarters Cisco Systems International BV Amsterdam, The Netherlands
Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at www.cisco.com/go/offices. CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0812R)
iv
Network Security Auditing
Dedications This book is dedicated to my beautiful wife Barbara, who also happens to be my best friend, and my two wonderful children Caleb and Sydney. Without your love and support, this book would not have been possible. I consider myself extremely lucky to have such a wonderful family in my life to share this journey with. You taught me the meaning of love and you make everything shiny and filled with joy.
About the Author Christopher L. Jackson, CCIE No. 6256, is a security technical solutions architect in the U.S. Channels organization with Cisco and is focused on developing security consulting practices in the Cisco partner community. Throughout his career in internetworking, Chris has built secure networks that map to a strong security policy for a large number of organizations including UPS, GE, and Sprint. Chris is an active speaker on security for Cisco through TechwiseTV, conferences, and web casts. He has authored numerous whitepapers and is responsible for a number of Cisco initiatives to build stronger security partners through security practice building. Chris is a highly certified individual with dual CCIEs (Routing and Switching & Security), CISSP, ISA, seven SANS GIAC certifications (GSNA, GCIH, GCFW, GCIA, GCUX, GCWN, and GSEC), and ITIL V3. Chris also holds a bachelors degree in business administration from McKendree College. Residing in Bradenton, Florida, Chris enjoys tinkering with his home automation system and playing with his ever-growing collection of electronic gadgets. His wife Barbara and two children Caleb and Sydney are the joy of his life and proof that not everything has to plug into a wall outlet to be fun.
About the Technical Reviewers Todd Reagan, CCIE No. 20273, is a systems engineer for Cisco Systems where he focuses on security technologies. Todd has more than 12 years of experience in IP internetworking, including the design and implementation of global enterprise networks. His focus has been on the security considerations of Internet peering, MPLS, and VPNs. He holds a bachelors degree in computer science from Texas A&M University in College Station, Texas. Brian Sak, CCIE 14441, CISSP, is a consulting systems engineer with Cisco Systems. He has more than 10 years of experience with network security. Prior to joining Cisco Systems, Brian provided consulting and assessment services for financial institutions, government agencies, and Fortune 500 companies.
v
Acknowledgments Writing a book is not an easy task. Gene Fowler summed up the writing process with the following quote: “Writing is easy. All you do is stare at a blank sheet of paper until drops of blood form on your forehead.” There is simply no way this book would exist without the many people who have helped me along the way. Most of what I know about auditing and security comes from the fine people at the SANS institute, who provide the very best in vendor-neutral security training. Thanks to Tanya Baccam in particular for educating me about the art of auditing networks for fun and profit. I am very lucky to have a strong support network at Cisco of the brightest and most talented engineers and hackers in the world. Todd Reagan helped with chapter 7, kept me straight on MPLS, and acted as a sounding board for my more insane concepts. Brian Sak played a major role in assisting with the writing of the wireless and password-hacking parts of the book. Victor Lam kept me sane and picked up the slack on my projects as I toiled away to get the book finished. You guys are incredible friends and words do not express how grateful I am for your support. A big thank you to my managers Rob Learned, Chad Bullock, and Tony Bouvia. Over the past few years, they allowed me the time to work on this project and gave me encouragement and support along the way. You three truly care about the success of your people and represent the best qualities Cisco has to offer. Thanks to Patrick Stark for being a fantastic friend and leader at Cisco. You always look out for us and help us get what we need. You are committed to our success and it shows. Last, but definitely not least, I want to thank Brett Bartow, Kimberley Debus, Ginny Munroe, and all of the people at Cisco Press for working with me as I juggled my day job and this book. I started this project when dinosaurs roamed the land, and you stuck with me regardless of my elastic concept of time. I doubt there is a more professional bunch anywhere in the publishing business.
vi
Network Security Auditing
Contents at a Glance Introduction
xxi
Chapter 1
The Principles of Auditing
Chapter 2
Information Security and the Law
Chapter 3
Information Security Governance, Frameworks, and Standards
Chapter 4
Auditing Tools and Techniques
Chapter 5
Auditing Cisco Security Solutions
Chapter 6
Policy, Compliance, and Management
Chapter 7
Infrastructure Security
Chapter 8
Perimeter Intrusion Prevention
Chapter 9
Access Control
Chapter 10
Secure Remote Access
Chapter 11
Endpoint Protection
Chapter 12
Unified Communications Index
447
1 27
87 131
177
289 317
359 397
237
153
61
vii
Contents Introduction Chapter 1
xxi
The Principles of Auditing
1
Security Fundamentals: The Five Pillars Assessment
2
Prevention
3
Detection
3
Reaction
4
Recovery
4
Building a Security Program Policy
4
5
Procedures Standards
6 7
Security Controls
7
Administrative Controls Technical Controls
7
8
Physical Controls
8
Preventative Controls Detective Controls Corrective Controls
8
Recovery Controls Managing Risk
8
8 9
9
Risk Assessment Risk Mitigation
10 14
Risk in the Fourth Dimension
16
How, What, and Why You Audit
17
Audit Charter
17
Engagement Letter Types of Audits Security Review
18
19 19
Security Assessment Security Audit
19
20
The Role of the Auditor
20
Places Where Audits Occur Policy Level
21
Procedure Level
21
21
1
viii
Network Security Auditing
Control Level
22
The Auditing Process
22
Planning Phase: Audit Subject, Objective, and Scope
22
Research Phase: Planning, Audit Procedures, and Evaluation Criteria Data Gathering Phase: Checklists, Tools, and Evidence Data Analysis Phase: Analyze, Map, and Recommend
23 24
Audit Report Phase: Write, Present, and File the Audit Report Follow-Up Phase: Follow up, Follow up, Follow up! Summary
25
References in This Chapter Chapter 2
26
Information Security and the Law IT Security Laws
27
27
Hacking, Cracking, and Fraud Laws
29
Computer Fraud and Abuse Act
29
Access Device Statute
31
Electronic Communications Privacy Act Title I: Wiretap Act
34
Title II: Stored Communications Act Title III: Pen/Trap Statute Intellectual Property Laws Economic Espionage Act CAN-SPAM Act of 2003 Reporting a Crime
38 39
41
42
43
44
Regulatory Compliance Laws SOX
37
39
Digital Millennium Copyright Act
State and Local Laws
34
46
46
HIPAA
48
Privacy Rule
50
Security Rule
51
Transactions and Code Sets Standard Rule Identifiers Rule Enforcement Rule GLBA PCI DSS Summary
52 52
54 55 59
References in This Chapter
60
52
25
24
23
ix
Federal Hacking Laws State Laws Chapter 3
60
60
Information Security Governance, Frameworks, and Standards Understanding Information Security Governance People: Roles and Responsibilities
61
64
Information Security Governance Organizational Structure Board of Directors
65
Security Steering Committee
65
CEO or Executive Management CIO/CISO
66
Security Director
66
Security Analyst
66
Security Architect
66
Security Engineer
67
Systems Administrator
67
Database Administrator IS Auditor End User
66
67
67 67
Spotting Weaknesses in the People Aspect of Security Process: Security Governance Frameworks COSO
68
Control Environment Risk Assessment Control Activities
69
70 70
Information and Communication Monitoring COBIT ITIL
68
70
70
71
75
Technology: Standards Procedures and Guidelines ISO 27000 Series of Standards NIST
Center for Internet Security NSA
80
DISA
81
SANS
82
ISACA
76
78 80
83
Cisco Security Best Practices
84
76
67
65
61
x
Network Security Auditing
Summary
85
References in This Chapter Web Resources Chapter 4
86
86
Auditing Tools and Techniques Evaluating Security Controls Auditing Security Practices
87 89
Testing Security Technology
91
Security Testing Frameworks
92
OSSTMM ISSAF
93
93
NIST 800-115 OWASAP
94
94
Security Auditing Tools
95
Service Mapping Tools Nmap
96
Hping
100
96
Vulnerability Assessment Tools Nessus
105
Packet Capture Tools Tcpdump
111
111
Wireshark/Tshark
114
Penetration Testing Tools Core Impact BackTrack
116
116
Metasploit
120 127
128
References in This Chapter
128
Security Testing Frameworks Security Testing Tools Chapter 5
101
101
RedSeal SRM
Summary
87
128
129
Auditing Cisco Security Solutions Auditors and Technology Security as a System
131
131
132
Cisco Security Auditing Domains
133
Policy, Compliance, and Management Infrastructure Security
135
Perimeter Intrusion Prevention
136
134
xi
Access Control
136
Secure Remote Access Endpoint Protection
137 138
Unified Communications
139
Defining the Audit Scope of a Domain
139
Identifying Security Controls to Assess
141
Mapping Security Controls to Cisco Solutions The Audit Checklist Summary Chapter 6
143
144
150
Policy, Compliance, and Management Do You Know Where Your Policy Is? Auditing Security Policies Standard Policies
154
158
Acceptable Use
158
Minimum Access
158
Network Access
158
Remote Access
159
Internet Access
159
User Account Management Data Classification Server Security
160
161
Mobile Devices
161 161
Physical Security Password Policy
161 162
Malware Protection Incident Handling Audit Policy
159
159
Change Management
Guest Access
153
153
162 162
162
Software Licensing
162
Electronic Monitoring and Privacy
163
Policies for Regulatory and Industry Compliance
163
Cisco Policy Management and Monitoring Tools
165
Cisco MARS
165
Cisco Configuration Professional Cisco Security Manager
167
169
Cisco Network Compliance Manager
171
xii
Network Security Auditing
Chapter 7
Checklist
174
Summary
176
References in This Chapter
176
Infrastructure Security
177
Infrastructure Threats
177
Unauthorized Access Denial of Service
177
178
Traffic Capture
178
Layer 2 Threats
179
Network Service Threats Policy Review
180
180
Infrastructure Operational Review
181
The Network Map and Documentation Logical Diagrams
182
182
Physical Diagrams
182
Asset Location and Access Requirements Data Flow and Traffic Analysis Administrative Accounts
Configuration Management Vulnerability Management Disaster Recovery
183
183 184 184
184
Wireless Operations
185
Infrastructure Architecture Review Management Plane Auditing
185
186
Cisco Device Management Access Syslog NTP
194
Netflow
195
Control Plane Auditing IOS Hardening
196
196
Routing Protocols
198
Protecting the Control Plane Data Plane Auditing
199
201
Access Control Lists iACLs
187
193
202
202
Unicast Reverse Path Forwarding Layer 2 Security
204
203
182
xiii
VTP
204
Port Security
205
DHCP Snooping
205
Dynamic ARP Inspection IP Source Guard
206
206
Disable Dynamic Trunking
206
Protecting Spanning Tree
207
Switch Access Controls Lists Protect Unused Ports Wireless Security
208
209
210
Wireless Network Architecture
210
Cisco Adaptive Wireless Intrusion Prevention System Protecting Wireless Access
212
Wireless Service Availability
213
Rogue Access Point Detection
214
General Network Device Security Best Practices Technical Testing
217
Router Testing
219
Switch Testing
221
Wireless Testing Checklist
230
Summary
235
225
References in This Chapter Chapter 8
236
Perimeter Intrusion Prevention Perimeter Threats and Risk Policy Review
237
237
238
Perimeter Operations Review
239
Management and Change Control
239
Monitoring and Incident Handling
240
Perimeter Architecture Review
242
What Are You Protecting? Perimeter Design Review Logical Architecture
244
Physical Architecture What Is the Risk?
243 243
245
246
Good Design Practices
247
216
211
xiv
Network Security Auditing
Auditing Firewalls
247
Review Firewall Design Simple Firewall
248
248
Screening Router and Firewall Firewall with DMZ
248
249
Firewall with DMZ and Services Network High Availability Firewall IOS Firewall Deployment
250
Review Firewall Configuration
251
Firewall Modes of Operation
252
Firewall Virtualization Filtering Methods
253
253
Network Address Translation Secure Management Logging
249
250
255
256
256
Other Configuration Checks Review Rule Base
257
Cisco Firewall Rule Basics Rule Review
256 257
259
Rule Optimization
260
The ASA Modular Policy Framework and Application Inspection 261 IOS Zone-Based Firewall Auditing IPS
263
265
How IPS Works
266
Review IPS Deployment
268
Review IPS Configuration
269
Protect the Management Interface
271
Administrative Access and Authentication NTP Configuration Signature Updates Event Logging
274 274
275
Review IPS Signatures
276
Signature Definitions
276
Event Action Rules
277
Target Value Rating
277
IOS IPS
278
271
xv
Technical Control Testing Firewall Rule Testing Testing the IPS
279 279
281
Conducting an IPS Test Reviewing the Logs Checklist
284
Summary
287
282
284
References in This Chapter Chapter 9
Access Control
288
289
Fundamentals of Access Control Identity and Authentication
289 290
Access Control Threats and Risks Access Control Policy
291
292
Access Control Operational Review
293
Identity Operational Good Practices
293
Authorization and Accounting Practices Administrative Users
294
296
Classification of Assets
297
Access Control Architecture Review
297
Identity and Access Control Technologies Network Admission Control NAC Components How NAC Works
298
299 300
NAC Deployment Considerations NAC Posture Assessment
303
Identity-Based Networking Services Deployment Methods NAC Guest Server NAC Profiler Technical Testing
302 304
305
306
306 308
Authentication and Identity Handling Posture Assessment Testing
309
Testing for Weak Authentication Checklist
313
Summary
315
References in This Chapter
315
309
308
298
xvi
Network Security Auditing
Chapter 10
Secure Remote Access
317
Defining the Network Edge VPN Fundamentals Confidentiality
317
318 319
Symmetric Encryption
320
Asymmetric Encryption Integrity
321
323
Authentication and Key Management IPsec, SSL, and dTLS IPsec
324
326
326
Secure Socket Layer
328
Datagram Transport Layer Security (dTLS) Remote Access Threats and Risks Remote Access Policies
329
330
Remote Access Operational Review VPN Device Provisioning
331
331
Mobile Access Provisioning
332
Mobile User Role-Based Access Control Monitoring and Incident Handling Remote Access Architecture Review Site-to-Site VPN Technologies Easy VPN
329
333
333 333
335
335
IPsec and Generic Router Encapsulation (GRE) Dynamic Multipoint VPN (DMVPN)
336
336
Multi Protocol Label Switching (MPLS) and Virtual Routing and Forwarding (VRF) VPNs 337 GETVPN
339
Mobile User Access VPN IPsec Client
340
341
Clientless SSL VPN
341
Cisco Secure Desktop
342
SSL Full Tunneling Client VPN Network Placement VPN Access Controls
344 345
346
Site-to-Site Access Controls Mobile User Access Controls Remote Access Good Practices
346 347 348
xvii
Technical Testing
350
Authentication IPsec SSL
350
351 352
Site-to-Site Access Control Testing
353
Mobile User Access Control Testing Monitoring and Log Review Checklist
354
Summary
358
References in This Chapter Chapter 11
Endpoint Protection Endpoint Risks
358
359
359
Endpoint Threats Malware
353
354
360
360
Web-Based Threats
362
Social Networking and Web 2.0 E-Mail Threats
366
Data Loss Threats Policy Review
365
367
368
Endpoint Protection Operational Control Review Current Threat Intelligence
370
Vulnerability and Patch Management Monitoring and Incident Handling Security Awareness Program Endpoint Architecture Review
373
373
374 374
Cisco Security Intelligence Operations SensorBase
375
Cisco Threat Operations Center Dynamic Update Function Web Controls
Web Security Appliance ASA IPS CSA
376
376 376
378 379 380
E-Mail Controls
380
E-Mail Policy Enforcement
381
375
375
370
xviii
Network Security Auditing
E-Mail Authentication Data Loss Prevention Web
383
383
E-Mail
384
Client
385
Patch Management Monitoring Web
381
386
386
386
E-Mail
388
MARS
388
Technical Testing
388
Acceptable Use Enforcement
388
Malware Detection and Quarantine
389
SPAM, Phishing, and E-Mail Fraud
390
Encryption
390
Patch Management and Enforcement Data Loss Prevention Testing Detection and Response Checklist
391
Summary
396
391
391
References in This Chapter Chapter 12
396
Unified Communications
397
Unified Communications Risks VoIP Threats
397
399
Denial of Service Confidentiality Fraud
390
399 401
401
UC Policy and Standards Review
403
UC Operational Control Review
404
User and Phone Provisioning
404
Change Management Asset Management
405 405
Call Detail Record Review Administrative Access
406
406
Vulnerability Management
406
Security Event Monitoring and Log Review
407
xix
Disaster Recovery
408
UC Architecture Review
408
Unified Communications Fundamentals H.323
410
MGCP SCCP SIP
409
412 412
413
Session Border Controller RTP and SRTP
416
Call Processing
416
Infrastructure Controls Switch Security
418
418
ACLs and Firewalling IPS
415
420
421
Gateway Protection Site to Site Wireless
422
422 423
Call Control Protection
423
Communications Manager Hardening
423
Authentication, Integrity, and Encryption Phone Proxy
426
Secure SIP Trunking
426
Toll Fraud Prevention Application Controls
428 431
Voice Endpoint Controls
432
Monitoring and Management Technical Testing
VLAN Separation Eavesdropping Gateway
433
434 434
436
438
Toll Fraud
438
Monitoring and Incident Detection Checklist
439
Summary
444
References in This Chapter
445
438
424
xx
Network Security Auditing
Icons Used in This Book V
Router
Edge Label Switch Router
NetRanger
Voice-Enabled Router
NAC Appliance
Switch Multilayer Switch
PIX Firewall Cisco ASA Appliance
ATM Switch
Authentication Server
Firewall Firewall Services Module
IP
U
Cisco Unified Cisco Unity Server Presence Server
Laptop
Phone Polycom
IP Telephony Router
PC
Ethernet Connection
Signaling Controller
TelePresence
SIP Proxy Server
IP Phone
Cisco Unified Communications Manager (CUCM)
Serial Connection
Wireless Access Point
File Server
Web Server
Analog Phone
PMC Mobile Access Phone
PBX
Network Cloud
Cisco Carrier Routing System
Command Syntax Conventions The conventions used to present command syntax in this book are the same conventions used in the IOS Command Reference. The Command Reference describes these conventions as follows: ■
Boldface indicates commands and keywords that are entered literally as shown. In actual configuration examples and output (not general command syntax), boldface indicates commands that are manually input by the user (such as a show command).
■
Italic indicates arguments for which you supply actual values.
■
Vertical bars (|) separate alternative, mutually exclusive elements.
■
Square brackets ([ ]) indicate an optional element.
■
Braces ({ }) indicate a required choice.
■
Braces within brackets () indicate a required choice within an optional element.
xxi
Introduction Mention the word audit to IT professionals and you will probably see their eyes glaze over as they imagine frightening visions of auditors with pointy tails, pitchforks, and checklists running around and pointing out all of the things they have done wrong to their manager. The purpose of a security audit is not to place blame or pick apart network design, but to ensure the integrity, effectiveness, and compliance of corporate security policies. Auditing provides the ability to test the assumptions companies have about how secure they think they are from threats and to gauge whether or not policies map to industry best practices and compliance laws. An organization’s level of risk is quantified by placing a value on the assets of the business and analyzing what impact the exploitation of vulnerabilities can have to the business as a whole. Auditors find risk and check to see whether the appropriate controls are in place to mitigate exposure to that risk. Auditing is not just about running a bunch of hacker tools in an attempt to break into the network. There are many types of audits, and the scope of an audit defines what the auditor inspects and how often. Many organizations require an annual audit of key systems by an outside firm (external audit), whereas others also mandate internal audits every six months or before and after any major IT project. If you are subject to PCI compliance requirements, you might need to have an audit preformed every quarter. The bottom line is if you aren’t auditing today, you will be forced to through regulations or encouraged to by industry best practices. It simply makes good business sense to measure the effectiveness of your security investment. The ultimate benefit of auditing is to continuously improve the processes, procedures, and controls put in place to secure valuable corporate assets. Businesses today have a responsibility to their customers to safe guard their confidential data. Numerous high-profile security failures have shattered that trust through carelessness while handling backup media and allowing millions of credit cards and financial records to fall into the hands of individuals determined to illegally profit at the expense of others. It takes only one major breach to appear in the news for a company to experience significant loss of shareholder value and sometimes even the total loss of the company itself. Having a policy and enforcing it are essential to protecting your business. Auditing that policy plays a key role in making sure that the policy actually accomplishes the goal of reducing risk and therefore protects key assets from loss. A large percentage of security failures can be minimized or prevented with a strong risk-based auditing program.
Goals The goal of this book is not to be yet another hacker book devoted to the latest tools and techniques for breaking into networks. Those skills are useful, but are not the primary focus of a security audit. There have been many books devoted to that topic and they are typically out of date by the time they come to press because of the speed in which technology changes. This book is about measuring the deployment of Cisco security technologies to mitigate risk. Baseline technical testing is covered from a process standpoint, but the focus is not on penetration testing.
xxii
Network Security Auditing
This book provides the reader with a practical guide to building an auditing and assessment program that factors in regulatory and industry security requirements, with real examples of how Cisco products can help address those needs. Recognizing that security is a system that relies on strong policy is the key principle. The value of the book lies in its ability to show real applications of Cisco security technology in the context of an auditing framework. Here are the key benefits of the book: ■
Provides an overview of the auditing process and introduces important regulations and industry best practices.
■
Demonstrates how to use commercial and open source tools to assist with the auditing process and validate security policy assumptions.
■
Introduces IT governance frameworks such as Cobit, ITIL, and ISO 17799/27001 while providing guidance about how to leverage each with Cisco security products.
■
Shows the reader how to segment security architectures into domains that provide a systems approach to auditing Cisco networks.
■
Supplies a detailed auditing checklist after each domain for the reader to utilize in an auditing program.
■
Provides design guidance for meeting auditing requirements and shows how complementary security solutions greatly increase the overall security posture of a company.
■
Guides the reader to build an auditing program that utilizes the techniques presented in the book.
Who Should Read This Book? This book is geared toward beginner to intermediate-level auditing and more specifically, auditing as it pertains to Cisco networks. The content is useful to anyone who wants to build a program to measure the effectiveness of Cisco security products. IT governance and auditing have common roots with financial auditing, and in many cases, it is ultimately the responsibility of the CFO in larger organizations. The language and procedures an IT auditor follows are similar to how a CPA might examine the books to certify that a business is keeping its records accurately and paying its taxes on time. Both disciplines keep there eyes open for fraud and try to anticipate how a system of controls can be circumvented. Every aspect of auditing, such as database auditing or web applications, is not covered as the focus of this book is on auditing the network. Numerous other books are dedicated to application and website auditing and would be better at providing a deeper understanding in those areas. If you are an IT auditor, security consultant, InfoSec manager, or someone who wants to assess his own network for good security deployment practices, then this book is for you.
xxiii
How This Book Is Organized The organization of this book breaks the material up into two major parts. The first part covers the principles of auditing and strives to teach the language and key components of the auditing process. This overview pulls together a number of techniques for identifying risk and shows how we must think like auditors in our network designs and device configurations. It also covers the major regulatory, industry compliance, and security framework initiatives. The section ends with a description of common auditing tools and techniques that can be used to assess and verify that the policy is enforced by technical controls. The second part, consisting of Chapters 5 through 12, covers the major Cisco security solution domains, which break down Cisco security technologies into seven categories that enable the auditor to examine network security as a system of integrated components rather than individual products. Each chapter discusses the risks, threats, policies, procedures, and technical controls that can be deployed to defend each domain. Best practices on network security design and configuration are covered, too. The reader is also supplied with a checklist that can be used as a starting point or reference for auditing. The following provides more detail on the contents of each chapter: Part I, “Principles of Auditing” Chapter 1, “Principles of Auditing”: This chapter defines security fundamentals including policies, procedures, standards, and controls. The basics of risk management and the how, what, and why audits are performed. In addition, the auditing process is outlined with a sixstep methodology that can be used in performing an audit. Chapter 2, “Security and the Law”: This chapter is about IT security laws and regulatory compliance with an overview of many of the major federal and state statutes governing IT Security. SOX, HIPAA, and GLBA are covered in addition to the PCI standard. Chapter 3, “Security Governance, Frameworks, and Standards”: Security governance frameworks such a COSO, Cobit, and ITIL help businesses coordinate people, process, and technology around security objectives. This chapter covers these frameworks, and also includes where to find source material that can be useful in building standards, procedures, and guidelines for security technology deployment. Chapter 4, “Auditing Tools and Techniques”: This chapter addresses the basics for evaluating security controls through technical testing. A combination of open source, commercial, and integrated Cisco testing tools are presented. Part II, “Mapping Cisco Security Controls to Auditing Requirements” Chapter 5, “Security Solutions Domains”: Security solution domains are introduced in this chapter as a method for assessing network security as an interconnected system. This chapter also discusses building checklists for security audits. Chapter 6, “Policy and Compliance”: Policy and compliance is the first auditing domain and is focused on assessing security policies. This chapter provides an overview of key security policies that businesses should have and how they should be constructed.
xxiv
Network Security Auditing
Chapter 7, “Infrastructure Security”: This chapter covers assessing baseline security features and configuration that should be implemented on Cisco routers, switches, and wireless devices. Chapter 8, “Perimeter Intrusion Prevention”: Assessing perimeter defenses is covered in this chapter, with a focus on firewalls and intrusion prevention systems. Chapter 9, “Access Control”: Access control technologies enable the enforcement of rolebased access requirements that follow the principle of least privilege. This chapter describes how to assess identity-based networking solutions and network admission control. Chapter 10, “Remote Access”: This chapter covers how to assess VPN technologies including site-to-site and mobile-user VPNs. Best practices for deployment and testing methods are also discussed. Chapter 11, “Endpoint Protection”: Endpoint protection is about preventing and detecting attacks targeted at users and their network devices. This chapter discusses methods that can be used to assess policies, procedures, and controls to protect endpoints from web, email, malware, and data loss. Chapter 12, “Unified Communications”: This chapter addresses auditing Unified communications systems policies, procedures, and security controls used to maintain confidentiality and defend against fraud.
Chapter 1
The Principles of Auditing
Do you want to know a secret? Security isn’t about hacking, nasty, malicious software, or the vulnerability of the day. Security is about maintaining a system and process that provide access to critical data without exposing your company or customers to excessive risk. Auditing is one of the most important aspects of maintaining that system, because it provides the opportunity to test assumptions about the security posture of networked systems and compare that posture with standards and regulations. Auditors ask the questions “How do you know that you are secure?” and “Can you prove that your security technology works?” The purpose of this chapter is to introduce the key principles of auditing and to describe the auditing process.
Security Fundamentals: The Five Pillars Auditing the security of a company requires that you have a good general understanding of what security is and what it is not. To understand security, it is critical that you realize that security is a process, not a product. Security is not a race with a finish line at the end, as you can never be 100 percent secure no matter how much money or time you spend on it. It’s just not possible to anticipate every vector of attack; but, with the appropriate planning and protective strategies in place, high levels of security can be achieved. Cisco is, fortunately, in a unique position to help companies achieve their security goals by providing the tools necessary to embed security features into many aspects of the network. This means security can be leveraged as a system to better map to the policies, procedures, and more importantly, the business drivers that cause companies to want to safeguard their assets. To understand security and to audit it as a system, you need to be able to identify how everything ties together conceptually. Security is a broad topic, and one of the few in information technology that literally touches all aspects of a business. From the data center to the break room, every function of a business has its own list of things that need to be protected from a certain level of risk. Managing risk is one of the most important fac-
Network Security Auditing
Figure 1-1
Recovery
Reaction
Detection
Prevention
tors in developing a strategy for protecting people, technology, and data. To focus security efforts and to make them manageable, it helps to break down the various aspects of security into the five pillars of security. Figure 1-1 shows the five pillars.
Assessment
2
Five Pillars of Security
Assessment The first step in protecting your company’s assets is to assess the environment. Most people (thrill seekers excluded) wouldn’t try to walk across a busy intersection with a blindfold on because not being able to see if the light is red or green could lead to a bad day. Understanding the business environment and direction helps identify the areas that the business deems most important and subsequently the most sensitive to disruption of services or theft. Much of what an auditor is asked to do in assessing risk requires sufficient knowledge of how the organization operates. Assessments document and identify potential threats, key assets, policies and procedures, and management’s tolerance for risk. The assessment process involves asking pointed questions. Just as if you were building a house, you would first start by surveying the land (available technology) to determine how suitable it is to build on. You would also need to know whether the area is prone to flooding (threats). How often does it flood (threat frequency)? Do you have the appropriate permits (laws and regulations)? What are the job site rules (policy and procedure)? What technology can you use to quickly and effectively build (technological components)? These questions and many more help the business plan a strategy for accomplishing its goals. Asking similar questions of the company’s security enables you to examine various scenarios to identify weaknesses in defenses or procedures. What is the probability that you will be hacked tonight and have a “CNN moment” tomorrow? It’s hard to say without a thorough assessment of the business and technology. Assessments are not something that are done once and then forgotten. As the business needs change and new services and technologies are introduced, regularly scheduled reassessments should be conducted. Doing this gives you an opportunity to test policies and procedures to ensure that they are still relevant and appropriate.
Chapter 1: The Principles of Auditing 3
Prevention Many engineers focus on technology when they think of prevention. True prevention is more than a firewall or a security appliance: It encompasses administrative, operational, and technical controls. Prevention is not just accomplished through technology, but also policy, procedure, and awareness. Policy must be documented and enforced with strict rules and consequences for violation. Documented procedures that utilize good security practices can help prevent misconfiguration, which is one of the most common methods that attackers use to compromise a system. Helping users understand what is and is not permissible, in addition to consistent and fair enforcement, goes a long way to lowering the overall risk to a company. Too often, organizations fixate on trying to prevent bad things from happening when in reality, they simply can’t stop everything. The magic box that Vendor X sells you can never anticipate all vectors of attack. This is where the concept of defense in depth comes into play. Defense in depth assumes that no control is perfect, so it helps to layer defenses so that you can compensate for known or unknown weaknesses in a technology or control. Technical security controls such as a firewall or intrusion prevention systems provide an important role in keeping a network secure, but they are not a silver bullet that you can plug in and expect to solve all of your security problems. Expect individual security controls to fail, but plan for the event by using multiple levels of prevention.
Detection Your car’s alarm system is one form of detection. Balancing your checkbook at the end of the month is another form of detection. Detection is how you identify whether or not you have a security breach or intrusion. Without adequate detection mechanisms, you run the risk of not knowing whether your network has been compromised. Dr. Eric Cole, author of Network Security Bible, said it best: “Prevention is important, but detection is a must.” If you can’t detect a compromise, then you run the risk of having a false sense of trust in your prevention techniques. One example of the importance of detection can be seen in the 1996 disclosure by Ohio University of hackers who gained access to systems that resulted in the loss of over 137,000 Social Security numbers. These miscreants had total access and control for over a year! Obviously, detection mechanisms were either nonexistent or were not properly monitored. Of course, the worst example I have heard about that highlights poor detective controls is from the United States Department of Agriculture, who announced in 2007 that it exposed over 150,000 farmers’ Social Security numbers because its database became live in 1981. Because no one can say for sure when it was actually connected to the Internet, over the 26 years it was active, it is estimated that the data was easily accessible for well over 10 years. Not a good thing! Detective controls help to identify security incidents and provide visibility into activities on the network. It’s important to detect an incident early so that you can formulate an appropriate reaction to recover services as quickly as possible.
4
Network Security Auditing
Reaction When prevention and detection are effective, reaction time is greatly reduced. No one wants to find out that they have a breach, but if you do have a compromise you need to do something about it now! Reaction is the aspect of security that is most concerned with time. The goal is to minimize the time from detection to response so that exposure to the incident is minimized. Fast reaction depends on prevention and detection to provide the data and context needed to recognize a security breach. Of course, just knowing about a compromise doesn’t help if you haven’t planned out in advance what to do. This planned and coordinated response is called incident handling. Some companies have a dedicated incident-handling team that can move in at a moments notice to reduce exposure time. Not everyone has the budget for these types of teams. Even if your company doesn’t have a dedicated team, some forethought and planning can mean the difference between everyone falling all over themselves trying to figure out what to do next and restoring key services. Automated response through technology is an important tool that reduces your reaction time to a security incident. But as good as automated response technologies are, you still need skilled people to handle the incident to ensure that the incident is real and not a hiccup on the wire. How quickly and efficiently incidents are handled is one of the most important tests to the effectiveness of a company’s security program. When the alarms go off, how you react can make all the difference in the world!
Recovery When your company has an eCommerce system that simply must be available to your customers or it processes hundreds of thousands of dollars in sales a minute, downtime is relatively easy to quantify. Recovery is where you play detective to determine what went wrong so that you can get the systems back on line without opening up the same vulnerability or condition that caused the problem in the first place. Do you patch the exploited vulnerability and recover the data from backup or do you have a bigger flaw in security controls that allowed the incident to occur? What was the reason that the system was compromised? How did the technical controls fail? Was there a misconfiguration? The recovery phase doesn’t end with bringing the system back online. There is also the postmortem aspect that determines what changes need to be made to processes, procedures, and technologies to reduce the likelihood of this type of vulnerability in the future. As an auditor, you must ensure that the organizations you audit have a plan for recovery that addresses these issues.
Building a Security Program Policies, procedures, and standards represent the foundation of a security program. These are the documents that detail the who, what, when, and how of protecting your business assets and resources. Yet, as important as these documents are, many organizations still don’t have a formal policy and procedure set for information security. If you ask the average IT professional about his company’s security policies and procedures,
Chapter 1: The Principles of Auditing 5
more often than not he will be hard pressed to answer your questions or produce a current copy. With regulatory compliance requirements such as SOX, GLBA, HIPAA, and PCI, this has started to change, but policy and procedure are still put low on the list of priorities. If they don’t help the company sell more widgets, then why would the company do it? The reality is that policies and procedures are how you plan for and hopefully reduce the risk of bad things happening to your data. When you work on a car or an airplane, there is a set of procedures that you should follow to ensure that you are consistently performing the correct operations in the appropriate order. It is essential to have security procedures documented before hand, so that you reduce the risk of having those “extra” parts at the end of the job or worse (in the case of the airplane), a major problem that puts lives at risk. An essential part of the auditor’s job is to examine an organization’s policies, procedures, and standards to ensure that they are complete, enforceable, and followed.
Policy Policies are essential for all businesses regardless of size or industry. They act as a social contract between the company and its users that define acceptable behavior with corporate resources. Policies also provide guidance about how a company approaches security by defining why the security measure is in place, what is being protected, and to whom the policy is applicable. An organization should receive its guidance about the technologies and controls that need to be implemented based on the goals defined in the policy. Think of it as the blueprint for building the structure of the security program. Just as you wouldn’t go to a lumberyard and build your house based on the wood and nails available, you should not implement security products and technology without a solid policy. At a minimum, a good security policy includes the following: ■
Purpose: Why the policy exists. This section includes the reasoning behind the policy, potential ramifications to the company if the policy is not followed, and how it supports the corporate mission.
■
Scope: To whom or what the policy applies. Is this a policy for contractors or fulltime employees? The scope should use job titles or functions to identify the employees instead of an individual’s name, so that the policy is unaffected as people change positions or go on vacation. Does the policy apply to development systems or key customer-facing servers? The scope section provides specifics about the assets and employees covered by the policy.
■
Policy statement: The policy requirements. This is the meat of the policy document and includes specific details about what is permitted or prohibited. The wording should be clear and concise and not be open to interpretation. A policy should not include specific products or configurations, as these areas are covered in procedures and subject to change.
■
Enforcement: Policy provides an enforcement point for discipline or prosecution in the event that an individual chooses not to play by the rules. Policy compliance is
6
Network Security Auditing
mandated through the disciplinary action statement. The enforcement section provides clear indication about the consequences of noncompliance with the policy and may include employment termination or other disciplinary actions. ■
Terms and Definitions: Clarification of terminology utilized in the policy statement, such as SPAM or malware.
■
Revision History: Summary of changes to the policy, with date of change, person or group that initiated the change, and a summary of what was changed.
The most important aspect of a good security policy is that the policy be clear, concise, and free of ambiguity. Providing examples helps to clarify the intent of the policy, but care must be taken to provide wording to cover areas that are not specifically mentioned. When writing policy, using imperative verbs such as will, shall, and must are essential to providing actionable direction. Trouble can arise when using subjective verbs such as should, may, and recommend because they represent an ideal state and do not imply a mandatory requirement or call to action. Many policies have been rendered ineffective and unenforceable by using subjective speech because the argument can be made that the policy is simply a recommendation and not a requirement. Telling an employee that he should follow the acceptable use policy is not the same as informing him that he must follow it.
Procedures Procedures are detailed instruction about how a policy is to be implemented. These documents provide an operations manual that an administrator can use to address bringing a new system online, backing up critical data, firewall configuration, and so on. It is difficult to enforce consistency without a procedural checklist to follow. Each policy document should include a companion procedure document. This enables the organization to update technologies and leverage best practices, while writing down the process and techniques used so that they can be replicated and checked. Procedure documents can provide an auditor with insight into how closely the company under audit follows security processes and makes great checklist material for the audit itself. The following is a list of items found in most procedure documents: ■
Purpose: Explains why the procedure is in place and what the source policy is
■
Scope: Explains who is responsible for the execution of the procedure and what situation or technology to which it applies
■
Warnings: Includes safety or security warnings that must be followed to maintain integrity
■
Procedure steps: Detailed procedures that must be followed to configure or provision the technology covered by the procedure
■
Revision history: Summary of changes and when the procedure was last updated or reviewed
Chapter 1: The Principles of Auditing 7
Standards As a kid, you might have gone to an amusement park excited about getting on the latest rollercoaster only to find out you weren’t quite tall enough to ride. This experience was a painful introduction to the definition of a standard. At the time, you might have thought that the cartoon character cutout that you didn’t measure up to was put there to spoil your fun, but it served a purpose. That purpose was to enforce height standards for the safety mechanisms built into the ride. Security standards serve the same purpose in that they dictate required controls or configurations that are considered best practices. Requiring alphanumeric passwords of 15 characters or more including special characters is an example of a strong password standard. Standards are the source material for the best practices that are used to create procedures. Fortunately, there are many well-documented standards available for use from standards bodies and Cisco. These standards and how to find them are covered in more detail in subsequent chapters. It is important to understand the reasoning behind a technology configuration or product selection choice that is used to address policy requirements. Cross-referencing procedures to standards documents such as the NIST 800 series or ISO27002 are great ways of justifying configuration and design decisions. With regulatory and industry requirements that mandate that companies exercise “due diligence” in securing their computing assets, it helps to be able to back up those claims through reputable third parties.
Security Controls Security controls are the building blocks of a security program. They are the tools that you implement to protect the confidentiality, integrity, and availability of important assets and data. Much of the assessment work that an auditor conducts is centered on the many controls that a company has (or doesn’t have) to reduce risk. Auditors are concerned with how effectively the controls accomplish the goals set forth by the security policy. Controls are typically thought of in terms of technology. Firewalls or IPS systems come to mind, but there are many types of controls that can be used to protect your systems. The primary classification of controls can be accomplished by grouping them under three main categories: administrative, technical, and physical.
Administrative Controls Administrative controls can consist of policies, such as Acceptable Use or security-awareness training. In addition, administrative controls can also consist of processes such as balancing the corporate books and security auditing. This type of control is typically focused on managing people, such as separation of duties, requirements for vacation, or any other rules that provide a deterrent to fraud or improper behavior.
8
Network Security Auditing
Technical Controls Technical controls consist of the technology that you implement to prevent or enforce behavior on the network or computing resources. They can include firewalls, Intrusion Prevention Systems (IPS), Host Intrusion Prevention Systems (HIPS), Role-Based Access Control (RBAC), or any other mechanism for enforcing policy.
Physical Controls If you want to deter people from walking through your yard, put up a fence. Although this won’t keep everyone out, it is an example of a useful physical control. In an office setting, physical controls include locked doors, key card access systems, video surveillance, guards, gates, and so on. This type of control is designed to restrict access to sensitive devices and areas. Each of the primary control groups can be further broken out into specific types of actions the control can take. Although there are others, the standard set includes preventative, detective, corrective, and recovery.
Preventative Controls Preventative controls enforce the confidentiality, integrity, and availability of data and assets. If the primary control is technical, then preventive controls are firewall rules, access control lists (ACL), or another technology used to block unauthorized access. Administrative preventative controls can include things like policies and warning banners. The primary category of controls (administrative, technical, and physical) gives context to how to implement the secondary controls.
Detective Controls Detective controls are the alarm systems built into various parts of the business to detect if bad things are happening. These can be video surveillance, firewall logs, an IPS, or Security Incident Event Management (SIEM) system. This type of control also includes financial and security audits.
Corrective Controls Corrective controls are reactionary in nature. An IPS blocking an attacking IP address is an automated corrective control that responds to the detection of malicious activity. A simpler example is a security guard double-checking that a door is locked when performing his nightly facilities check. A corrective control is a mechanism used to mitigate a security incident and is likely implemented after a detective control has discovered the problem.
Chapter 1: The Principles of Auditing 9
Recovery Controls Recovery controls are like parachutes on a plane. Hopefully, you won’t need them, but they are there in case you do. Backup systems, redundant power supplies, and spare parts are all examples of recovery controls. Restoring services is the goal of these controls. An auditor is responsible for determining whether or not the controls implemented are sufficient to protect the assets or meet the business requirements outlined in the policy documents. Do the controls adhere to best practice and are they in compliance with regulations and law? An auditor might also be asked to provide recommendations about how to improve the controls to better address current risks. The interaction between the various controls discussed provides a nice view into whether or not a company under audit has addressed its controls in a thorough manner. Table 1-1 provides an example of how an auditor can logically group controls for a remote access (Virtual Private Network (VPN) solution to ensure it has been addressed. Table 1-1
Remote Access VPN Control Groupings Administrative Technical
Preventative Remote access VPN policy
Physical
Firewall access rules, Secure Data center requires keycard, Socket Layer (SSL) / IPSEC password recovery disabled on VPN appliance VPN, NAC posture assessment
Detective
Video surveillance, alarm senVPN user access NAC Posture Assessment, review intrusion prevention system sor on door to equipment (IPS), Mentoring Analysis and Response System (MARS) log review
Corrective
Access revoca- NAC remediation tion procedures
Auto locking doors, nightly security checks
Recovery
Recovery proce- VPN cluster, modem pool dures documented
SMARTnet with HW replacement, Uninterruptible Power Supply (UPS)
Managing Risk You manage risk every day of your life. When you get into a car, the real risk of getting into an accident on the way to your destination exists. This is a risk that everyone who drives realizes, so in order to mitigate the risk of something bad happening, you follow posted road signs, stop at stoplights, and signal before you change lanes. This can help to reduce the chances of something unpleasant happening, but it can’t completely eliminate risk. There is always a person who drives aggressively or runs the red light. To reduce the impact of the event (pun intended)—in this case, a car wreck—you purchase vehicles with
10
Network Security Auditing
airbags, crumple zones, and antilock brakes. These technologies can help minimize potential damages (physical well being is the asset in this case) and hopefully give you enough time to react to the event so you can avoid it or walk away without any major harm. Technology can help dramatically reduce risk, but only if applied in a manner that puts investments where they can do the most good. Airbags that go off 10 minutes after a wreck (or not at all) don’t provide very much protection. An improperly installed IPS does not provide any meaningful data and can potentially degrade your ability to detect a real attack by generating unnecessary log data. Finding a real attack in this situation is like finding the proverbial needle in a haystack. How much security is enough security? This is a question that plagues IT managers because there are no easy answers. Most organizations answer this question by implementing a risk-management program. SOX, GLBA, HIPAA, and PCI require a riskmanagement program because there is no one-size-fits-all approach to securing corporate assets and data. Organizations must understand the risks they face, and the only way to do that is through assessing risk.
Risk Assessment There are many techniques used to assess risk. Some measure risk through numerical models, and others use experience and professional opinion to measure risk. No matter how good your models are or how extensive your research is, a portion of the equation always has a level of uncertainty. Risk by its very nature does not lend itself to a numeric value that is 100 percent accurate. Of course, if you can unerringly determine whether or not something is going to happen, I am sure you would move to Las Vegas and hang out at the casinos instead! To better understand the various models, it is necessary to define a few important terms: ■
Asset: If you took an accounting class, you probably had the whole debits and credits thing drilled into your head. Putting a numeric value to an asset is easy for tangible items such as how much your routers cost or employee payroll, but the real challenge is in putting a value on the intangibles such as goodwill, opportunity cost, or loss of reputation. In summary, an asset is anything of value to your organization.
■
Threat: A threat is any type of event that can cause loss and is usually measured in terms of probability or likelihood of occurrence. In the case of viruses, companies can see hundreds of infection attempts a month, so the threat of being exposed (though not necessarily infected) to a virus is close to 100 percent.
■
Vulnerability: A vulnerability is a weakness that can result in a threat being able to compromise an asset. Hardware and software vulnerabilities are discovered on a daily basis, but the greatest number of vulnerabilities still comes from default configurations. One other thing to note is that just because a system is “vulnerable” does not mean that the vulnerability can be exploited. Hardening systems by removing unneeded services can help to reduce the potential vectors of attack by preventing access to vulnerable services.
Chapter 1: The Principles of Auditing 11
■
Cost of exposure: Cost of exposure refers to the total tangible and intangible cost associated with an asset being compromised. Many times the actual monetary value of an asset is a small portion of its total value to the organization. A $10,000 database server might have 1 million dollars worth of data on it. You have to understand the business processes and interconnections to assess the true cost of exposure. Interdependent systems can grind to a halt if a 25-cent part breaks.
The risk assessment process defined by NIST 800-30 provides an excellent guide to identifying risk to systems and processes. NIST 800-30 utilizes the following steps: Step 1.
Characterize the system: Understand the business processes and interdependency of the systems under review. Where does it fit into the organization and how is it used? What are the software and hardware versions deployed. How is it configured?
Step 2.
Identify threats: Identify the threats to confidentiality, integrity, and availability. Extortion, corporate espionage, data theft, and disasters are all examples of potential threats.
Step 3.
Identify vulnerabilities: Catalog the services and protocols used to generate a list of potential attack vectors. Software, hardware, and configuration can all have potential vulnerabilities. Automated software tools help, but experience and knowledge find the ones that scanning tools miss.
Step 4.
Analyze controls: Identify whether or not the controls in place are sufficient when compared to the risks a successful compromise would have to the business. Each of the primary control categories—administrative, technical, and physical—must successfully address prevention, detection, correction, and recovery for the threats and vulnerabilities identified. This analysis finds which controls are missing or inadequate.
Step 5.
Determine the likelihood of an event: Utilize the quantitative or qualitative approach to rank the likelihood of an event happening. The next section addresses a number of methods for doing this.
Step 6.
Analyze the impact of an event: Attempt to put a monetary value on the impact a potential event can have to the company as a whole. Management understands the severity much better and is in a better position to allocate resources if it has an idea of how much money the event could cost the company.
Step 7.
Determine risks: The values identified in previous steps are compiled to provide a snapshot of the risks the business faces. This step provides the prioritized list of security issues that need to be addressed.
Step 8.
Recommend controls: A key part of an auditor’s role is to recommend controls to reduce risk. These recommendations help the organization under audit better protect its assets.
12
Network Security Auditing
Step 9.
Document results: Documenting the results of the risk assessment helps to show due care and due diligence. This step is also where the results of the process are presented to management.
Risk, as it relates to information security, can be defined quite simply as the probability or likelihood that a threat will exploit a vulnerability and cause damages. Although this definition might sound simple, there is some work that needs to be done to figure out the values you need to build your equations. There are two main approaches to risk analysis; one is quantitative and the other is qualitative. The quantitative approach uses formulas to equate the frequency of a risk to a monetary value. These formulas themselves are not particularly complex, but the data used to feed the variables can be time-consuming and difficult to compile. Most of the data that exists is historical, and the rate of change that is seen in technology makes it difficult to maintain accurate values. In security, you don’t have actuarial tables that give the average number of incidents per type of company or industry—similar to what is seen with insurance claim data—because most organizations simply do not track security incidents accurately or consistently. The most widely used source for this type of data generally comes for the yearly FBI/Computer Security Institute report on cyber crime. This report provides the number of reported incidents in various categories, such as data theft or security breaches; however, you are on your own to figure out what these events cost, as it is different per company and employee. You might have a worm infect a laptop, causing a user to be unable to work for a day. Calculating the technician time in reloading the machine might give you two hours at $60 per hour or $120 for that incident. What is often under reported is the total cost in productivity and lost data. You have the technician’s time accounted for, but what about the individual who can’t do his job because of the downed laptop? What about the lost report that took two weeks to complete and now must be rewritten because key files were corrupted? It’s more difficult to quantify those types of losses. Still, many organizations have standardized on quantitative methods for risk analysis. Auditors must be aware of how these formulas work. Here are a few classic examples: ■
Single Loss Expectancy (SLE) = Asset Value x Exposure Factor: SLE is a formula that determines the expected cost of loss to an asset based on the exposure to the event that the asset incurs. The exposure factor represents how much damage there is as a percentage of loss to the asset. The percentage of loss ranges from 0 (no damage) to 100 percent (total loss). Unless there is complete destruction of the asset, the exposure factor is less than 100 percent. If a web server database worth $100,000 is corrupted during an attack, and the backup is able to recover only 70 percent of the data, then the exposure factor would be $30. A $100,000 asset x percent (EF) = $30,000 loss.
■
Annual Loss Expectancy (ALE) = Single Loss Expectancy x Annual Rate of Occurrence: The ALE calculation uses the output of the SLE formula and multiplies it by the expected number of occurrences of the event in a single year. If the web server is hit by an attack twice a year, then ARO would be 2. If you have never been hit but estimate that you will experience an attack sometime in 10 years, then ARO
Chapter 1: The Principles of Auditing 13
would be 0.1. After you determine the ARO, you can then multiple it by the SLE to determine the ALE: $30,000(SLE) x 2(ARO) = $60,000(ALE) ■
Countermeasure Value = ALE Before – ALE After Annual Countermeasure Cost: To determine how much you should spend on countermeasures to reduce the risk to assets, you can use the data generated by the previous functions to build a cost benefit analysis to help justify the purchase of a new countermeasure. During the postincident analysis, it was determined that the attack could have been prevented through a combination of an IPS and better backup software for recovery. The total cost of the new countermeasures is $10,000. If you have $60,000 (Before ALE) – $20,000 (after ALE savings from the new countermeasure) – a $10,000 countermeasure cost, then you have added $30,000 of “value” to the organization by purchasing the countermeasure. This enables you to determine that purchasing this countermeasure is a good use of your security investment and saves the company $30,000.
■
Return on Security Investment (ROSI) = (ALE x Percent of risk mitigated) – Countermeasure cost) / Countermeasure cost: The ROSI calculation is used to determine a return on investment value for a security countermeasure. You utilize ALE and multiply it by the percentage improvement in effectiveness of the new countermeasure and then subtract it by the cost of the countermeasure. Then you divide the total by the cost of the countermeasure, to determine the rate of return. To arrive at a Risk mitigation percentage, you should test the equipment in a lab or rely on a neutral testing organization to determine an appropriate effectiveness rate. Continuing with the DoS example, your $60,000 (ALE) x 80 percent (increase in risk mitigation based on testing) – $20,000 (cost of the countermeasure) you get $28,000, which would be how much you should save from the increased effectiveness of the countermeasure. If you divide $28,000 by $20,000 (the cost of the countermeasure) you can hope to realize a return on security investment of 140 percent. Not a bad deal!
Although none of the quantification techniques described are 100 percent accurate, there is still value in having a consistent and replicable way to determine how an organization invests in security. These are simple examples that require research and time to increase accuracy. Because a large number of companies don’t have the time or inclination to do this level of number crunching, the qualitative methods for determining risk have become increasingly popular. Qualitative risk analysis is less concerned with the numbers, and more interested in finding which assets are exposed to the greatest level of risk. The power of the qualitative approach is that it can provide a measurement tool that anyone can understand without majoring in statistical analysis. The results are actionable, and the rating system can be anything that the organization is comfortable with, such as high, medium, and low. The variables threat, vulnerability, and exposure are similar to the quantitative approach, but the ways in which we arrive at the values are quite different. The qualitative approach uses the following simple formula: Risk = Threat x Vulnerability x Impact of Exposure
14
Network Security Auditing
Assets are what you must try to protect, and those assets can be a database, business process, network access, or anything else that is an important part of how you do business. The easiest way to identify threats is to use the CIA triad of Confidentiality, Integrity, and Availability. These three areas represent the primary aspects that businesses attempt to protect, so if you measure your assets against CIA, you can determine potential threats to that asset. Confidentiality is keeping data private and out of unauthorized hands. Integrity is about ensuring that unauthorized parties do not tamper with data. Availability is concerned with keeping the service or system up and running. After you determine your potential threats, you need to classify them based on the likelihood of an event happening. There are always potential threats out there, but some of them are just not practical. That’s where the vulnerability aspect of the formula comes into play. A threat with no vulnerability is still a threat, but there is no risk to the asset because if any one of the variables is zero, then risk is zero. Risk depends on the presence of a threat and a vulnerability. Take, for example, the threat of a teardrop attack. The teardrop attack took advantage of a vulnerability in the IP stack where a maliciously crafted fragmented packet with overlapping offsets could cause a kernel panic or blue screen of death. In 1997 this was a real risk because the vulnerability was present in a large majority of Windows and Unix-derived IP stacks, and the threat of someone using this attack was great due to easily accessible exploit code. Unless you are running very old or devices that aren’t patched, this is not something you would be concerned with today. The risk of this attack to modern operating systems is virtually nonexistent. The last variable in the simplified risk equation looks at the impact to the organization if the threat is successful. If the threat is stealing customer credit card information, you can feel confident that the threat level is high because there is significant evidence that there are plenty of individuals with the skills, resources, and inclination to engage in this type of crime. If a company houses its customers’ credit card information in a database that is connected to an Internet-accessible web server, then the potential for a vulnerability that could be exploited is also high. The impact of this event could be high, too, because customers do not forgive a company that experiences a breach like this. Based on this simple scenario, you can determine that the risk is high to this asset and it would be wise to focus your efforts on protecting the asset by providing controls and countermeasures that can reduce the risk of a compromise happening. The point of all of this is to make sure that the organization that is being audited has addressed these issues in a manner that reduces the total risk to the organization. Auditors need to understand how to perform risk analysis to determine whether or not the controls are in place and appropriately address the level of risk to the asset. The auditor’s role is also to provide recommendations for reducing risk, and that takes us to the next area of risk management: risk mitigation.
Risk Mitigation After you have determined that there are legitimate risks to the company’s assets, the next step is to figure out how to address those risks. The goal of most risk-management programs is to prove that the organization has preformed “due diligence” or “due care.”
Chapter 1: The Principles of Auditing 15
Due diligence and due care are legal terms that seek to determine whether a company or individual has been negligent in their duties. In the case of information, security organizations need to act (and document those actions) in a manner that secures business assets to a level that is prudent and reasonable given their value and risk. This prudent man rule is another aspect of law that comes up often when discussing risk mitigation. Directors and managers might be held personally liable for negligence of duty, if it is proven that they did not provide the necessary environment to protect the assets they have been charged with securing.
Note—It is important to involve legal council to ensure compliance with local and federal law. I am not a lawyer (I don’t even know any good lawyer jokes), and this book isn’t a substitute for good legal advice. Mitigating risk is not simply about buying a product or writing a policy. Purchasing technology can be a component of addressing risk, but there are a number of options available. The following list details the choices a company must make when managing risk: ■
Accept the risk: A company can choose to accept a risk for many reasons. If the probability of a threat successfully exploiting a system is unlikely or the cost to protect the system is so high that it would be cheaper to recover the system in house, then an organization might choose to accept this risk as part of doing business. The danger here is in underestimating the total cost of an exploit and not fully realizing the impact of the event to the business or customers.
■
Avoid the risk: Sometimes in business, the reward is just not worth the risk. Companies might choose to not conduct business in a way that opens them up to risk. If you have a retail establishment and store credit card information on your Point of Sale (POS) systems as part of your processing of daily transactions, you run the risk of credit card information being stolen because you have this data scattered across all of your POS systems in all of your stores. You can avoid this risk by not storing the data on the POS system and simply running your credit card transaction through a headquarters-based clearinghouse with much higher levels of security.
■
Transfer or share the risk: The simplest mechanism for transferring risk is to purchase an insurance policy. Other ways include outsourcing the risky service to a third party and building in strict service-level agreements (SLA) and contracts so that they are responsible for securing the data. Of course, regardless of who is “responsible” for an incident, there is still the damage to reputation that can occur with a data breach.
■
Reduce or mitigate the risk: Implementing controls and countermeasures are how you can reduce or mitigate risk. You can avoid the risks on the Internet by simply unplugging external connections, but you lose all of the benefits that a global marketplace gives you. Purchasing countermeasures and implementing controls is a much less drastic response to protecting your systems.
16
Network Security Auditing
■
Ignore the risk: This is the most dangerous of all options, because it can have dire consequences to shareholders and the organization as a whole. Ignoring risks does not make them go away and could cost your company everything in the end.
Risk in the Fourth Dimension No, this isn’t the section about Euclidean geometry or a discussion about Einstein’s theory of relativity (I know you are disappointed!). Instead, the Fourth dimension as it applies to information security is about time. Time is important in security because it enables us to measure the effectiveness of countermeasures based on how long they are exposed to a particular event. When you think about the security of your data, how well do your countermeasures stand up to a sustained attack? When you want to purchase a safe, time is one of the most important factors in picking the correct one to do the job. If you go out and purchase a safe for your valuables, you have to decide what level of protection you need because no safe is impenetrable. Given enough time and the right resources someone can get into it. Safe manufacturers know this, so they rank their safes based on how long it takes an expert to break in. This is called Net Working Time and is displayed on a sticker or other label to indicate how well the safe did. If it is rated as a TL30, it should take an expert with grinding wheels, high-speed drills, saws, and hammers 30 minutes to get in. Of course, the time could be significantly less if you have a little C4, but you run the risk of an accident and destroying the items inside. A safe with TRL30 should withstand all of the hand tools and a gas-cutting and welding torch. The safe isn’t designed to prevent someone from getting in forever, just long enough for you to detect that he is there and hopefully catch him before he makes off with your valuables. The concept of using time as a measurement tool for security is not new. Many people have contributed to this concept, but Winn Schwartau was the first to write a book applying these techniques to information security. Schwartau’s book, Time Based Security, details how to use time as a mechanism to determine whether or not the countermeasures are sufficient. This methodology—although not the only one to consider in risk assessment—gives us another tool that puts risk-management strategy into fairly simple terms that can help identify the areas that need the most attention. The following formula can be used to determine exposure time: Exposure = Detection + Reaction This technique uses detection and reaction as variables to measure potential exposure time to an incident. If you have a fire, the quicker you can detect it and react to it (put it out), the less damage you will have. Let’s work through a quick example. Let’s say there is an organization selling vitamins on the Internet through an online shopping cart. The company operates its own web server and database and processes credit cards through its website. A new vulnerability in the web server is discovered and an exploit code is released that can enable an attacker to gain control of the server. On average the security analysts review vulnerability reports every 24 hours. After a vulnerability is detected, it takes about two hours to update the server and bring it back into operation. The formula to represent this scenario would look like this: Detection (24 hours) + Reaction (2 hours) = 26 hours. This means that there is an exposure time of roughly 26
Chapter 1: The Principles of Auditing 17
hours. For those 26 hours, any customer placing an order can have his credit card information stolen, or the database itself can be siphoned off by the attacker. Many organizations do not have people dedicated to monitoring these types of events 24/7, so the detection time is drastically different. You can, however, easily see that you have a major problem that requires you to do something to tilt the equation back to the correct direction. Prevention technologies can be used to decrease detection and reaction time, reducing exposure. An IPS appliance can decrease detection and also reaction time based on new signatures being deployed. If an IPS receives a new signature every 4 hours, then your exposure in the previous example would be cut by 22 hours. Using a web application firewall might completely prevent a successful attack of this nature in the first place, changing the organizations exposure time to zero. Utilizing time-based security measurement provides a relatively simple method of determining how effective countermeasures are in real-world scenarios.
How, What, and Why You Audit So far this chapter has spent a lot of time talking about the fundamentals of security, covering many areas that are essential knowledge for someone performing an audit. Auditing is most concerned with risk and how that risk is addressed. Are the controls put in place effective at protecting the assets? The only way to know is to test them. That is why the role of the auditor is so essential to good security. This section discusses the details of the audit process and provides an overview of the types of audits and key aspects that help make an audit successful.
Audit Charter So what’s the difference between a hacker and an auditor? Permission. The auditing, by nature, includes having access to sensitive data and systems. This function is defined by an audit charter, which is a document that defines the purpose, responsibility, authority, and accountability of the auditing program. This document helps to clearly define the requirement for performing audits and provides justification as to why the auditor should be given access to critical systems. An audit charter usually applies to an internal corporate auditing organization and will include the following: ■
■
Purpose of the auditing function ■
Create a mission statement.
■
Set goal objectives.
■
Define the scope.
Authority ■
Access rights to audited systems.
■
Obtain support of personnel to accomplish audit goals.
18
Network Security Auditing
■
■
■
Use technology to test auditing controls.
■
Perform risk assessment.
Responsibility ■
Develop an audit plan.
■
Maintain professional expertise.
■
Issue reports on results of audits.
■
Make recommendations for reducing risk.
■
Maintain integrity and professional standards.
Accountability ■
Report deficiencies about control effectiveness to executives.
■
Provide reports about the current risk.
■
Ensure the organization complies with standards and legal requirements.
Engagement Letter When an outside party performs an audit, an engagement letter must be obtained. This document functions in a similar manner to the audit charter, but is usually written per project. It includes many of the same items as the audit charter but is more specific about the deliverables of the current engagement. The engagement letter includes: ■
■
■
Authority ■
Who contracted for the audit
■
Rights of access to systems
■
The signature of the company executive
Responsibility ■
Scope of the audit
■
Specific deliverables
Accountability ■
Who is to receive the final report
■
Agreed upon completion dates
Chapter 1: The Principles of Auditing 19
Types of Audits Audits can be broken down into a number of types, from the simple analysis of security architecture based on opinion, to a full-blown, end-to-end audit against a security framework such as ISO27001. The difference between types of audits is in what the auditor based the findings on and how detailed the audit’s scope is.
Security Review A security review is when you examine the security posture of an organization based on professional experience and opinion. Think of a security review as a site survey. In this type of examination, you look for issues that stand out as a way to help define the starting point for further activities. Running a vulnerability scanner such as Nessus would fall under this category. The tool generates a list of potential security issues, but the data must be analyzed further to determine on what needs to be acted on. This is the most basic form of security analysis and the primary output is in the form of an opinion. Examples include: ■
Penetration test
■
Vulnerability scan
■
Architecture review
■
Policy review
■
Compliance review
■
Risk analysis
Security Assessment Security assessments utilize professional opinion and expertise, but they also analyze the output for relevancy and criticality to the organization. The analysis aspect of an assessment attempts to quantify the risk associated with the items discovered to determine the extent of the problem. If you have two servers with the same vulnerability, but one is your financial server, and the other operates as a print server a security assessment would rank the financial server as a high risk and the print server as a lower risk based on the severity and damage potential. The biggest differentiator between an assessment and a review is the depth to which the auditor examines the system and analyzes the results. Examples include: ■
Vulnerability assessment
■
Risk assessment
■
Architecture assessment
■
Policy assessment
20
Network Security Auditing
Security Audit A security Audit examines the organization’s security posture against an industry standard (ISO27001 or COBIT) and/or regulatory compliance such as HIPAA or PCI. An audit includes review and assessment; it also conducts a gap analysis against standards to measure how well the organization complies. Audits take into account people, processes, and technologies, and it compares them to a benchmark in a standardized and repeatable way. Examples include: ■
Compliance audit
■
Policy audit
■
Procedure audit
■
Risk audit
The Role of the Auditor The role of the auditor is to identify, measure, and report on risk. The auditor is not tasked to fix the problem, but to give a snapshot in time of the effectiveness of the security program. An auditor might be asked to make recommendations about what needs to be done to fix a deficiency in a control, but the objective of the auditor is to report on security weakness. Auditors ask the questions, test the controls, and determine whether the security policies are followed in a manner that protects the assets the controls are intended to secure by measuring the organization’s activities versus its security best practices. The auditor functions as an independent advisor and inspector. The auditor is responsible for planning and conducting audits in a manner that is fair and consistent to the people and processes that are examined. Auditors must have appropriate access and cooperation or the audit runs a risk of not being successful or worse, not identifying critical items that could jeopardize key systems. The auditing charter or engagement letter defines the conduct and responsibilities of an auditor. Depending on how a company’s auditing program is structured, ultimate accountability for the auditor is usually to senior management or the Board of Directors. The auditor must be independent of the business entity being audited or the impartiality of the audit can be called into question. Auditors are usually required to present a report to management about the findings of the audit and also make recommendations about how to reduce the risk identified. Conflicts of interest can preclude an auditor from conducting an assessment of a particular system or organization. If you were the one that installed the firewall, it doesn’t make sense for you to also be the one to audit it. Auditors are expected to excuse themselves from an audit if they feel that there is potential for a conflict to exist.
Chapter 1: The Principles of Auditing 21
Places Where Audits Occur Depending on the scope of the audit, an auditor can be asked to examine many different systems and processes. When defining the scope, the specific items to be audited fall under the category of policy, procedure, or control. Some audits are concerned only with policy review and nothing else, whereas other audits might assess all aspects of security by looking at all three areas. Regardless of how detailed the audit becomes, the three categories are not islands unto themselves. They represent interlocking components of the overall security strategy.
Policy Level Auditing policy entails examining current policy to ascertain whether or not the policy meets the objectives of the business. It should be specific enough while not being so specific that you can’t change your firewall rules without changing the policy. The policy itself should stay consistent regardless of how you accomplish executing the objectives of the policy. Of course an auditor might also find that the organization does not have a policy for a potentially risky business system, which would mean that the auditor would recommend the creation of a policy and give examples based on industry standards. Policy is the cornerstone of security, so care and attention need to be paid in the creation of these documents. Techniques for auditing policy include: ■
Categorize policies into Administrative, Operational, and Technical.
■
Ensure that the policy meets business objectives.
■
Check for compliance to ensure the policy is being followed and enforced.
■
Compare it against best practices (SANS, ISO, and COBIT).
■
Identify gaps.
Procedure Level Procedures represent how a company implements policy. Here is where all of the detail resides on how the company will go about protecting its assets. From an auditor’s perspective, procedures provide a lot of information in creating checklists to measure how the business applies policy and controls. If a company has a policy that requires all systems to have a personal firewall installed, configured, and active at all times—but does not have a consistent procedure documenting how the firewall is to be configured—then the company will more than likely have a hard time enforcing this policy. These are the kinds of areas that auditors can help with by recognizing deficiencies in policy implementation and recommending solutions to improve security. Techniques for auditing procedures include: ■
Compare procedures to policies to ensure that the procedures follow the spirit of the policies.
22
Network Security Auditing
■
Check for configuration compliance.
■
Compare procedures with industry standard practices.
Control Level Many audits and assessments are focused on the control level. Controls can be technical, administrative, or physical, and they can represent a key component in reducing risk. The auditor is concerned with whether or not the control provides a level of protection greater than the level of risk. Techniques for auditing controls include: ■
Test control functionality.
■
Inspect configuration.
■
Inspect logs.
The Auditing Process The auditing process can be easily broken down into a number of phases. Each phase builds on the last with the ultimate product being a report that documents the findings of the audit. Having a good framework to conduct an audit makes the process run smoothly and helps to eliminate opportunities for mistakes and inconsistencies that reduce the accuracy of the audit. The phases of an audit are: ■
Planning phase: Audit the subject, objective, and scope.
■
Research phase: Plan, audit procedures, and evaluate criteria.
■
Data gathering phase: Gather checklists, tools, and evidence.
■
Data analysis phase: Analyze, map, and recommend.
■
Audit report phase: Write, present, and file the audit report.
■
Follow up phase: Follow up, follow up, and follow up!
Planning Phase: Audit Subject, Objective, and Scope The first and most important phase of auditing is in determining the overall strategy of the audit. What is the purpose of the audit? If the audit is in response to regulatory compliance requirements, the auditor must compare processes and procedures with those mandated by law. Alternatively, an audit of a newly installed firewall would have a different objective and be specific to one particular control. To figure out the degree and depth of the audit, there is a bit of work that needs to be done before sending the first test packet or stepping foot on site: Step 1.
Identify the subject of the audit. Is the audit focused on people, process, or technology?
Step 2.
Determine the objective. What is the purpose of the audit?
Chapter 1: The Principles of Auditing 23
Step 3.
Determine the scope. What systems, processes, or organizations are to be audited?
Step 4.
What is the timeframe of the audit?
Research Phase: Planning, Audit Procedures, and Evaluation Criteria After you determine what the goal of the audit is, the next step is to formulate a plan for accomplishing the objectives of the audit. This phase will include: ■
Identify the resources needed: skills and technologies.
■
Identify the organizational structure, process, and data flow.
■
Determine who in the organization under audit should be interviewed or involved.
■
Identify logistics information, such as which facilities or locations need to be reviewed.
■
The procedures used to test controls must also be identified, including what types of tools will be used.
■
Measurement and evaluation criteria should be selected (for example, COBIT, ISO27001, or PCI technology standards).
■
Review corporate policies and procedures.
■
Build auditing checklists.
Data Gathering Phase: Checklists, Tools, and Evidence Data gathering is the phase in which the auditor conducts the actual audit itself. The checklist that was created in the research phase is used to measure compliance with the standards and practices that were selected as benchmarks. The checklist acts as a guide that directs the auditor on where to look and what to expect. Many tools might be used to test the various controls to determine functionality and to generate the evidence that is used later in the analysis phase. The auditor looks to find “proof” or evidence of compliance with policy and standards. The auditor does the following: ■
Examine system documentation.
■
Conduct surveys on the effectiveness of policies and procedures.
■
Conduct interviews of key personnel.
■
Observation of systems and process in action.
■
Review previous audits to look for trends.
■
Review logs and reports.
■
Inspect technical control configuration.
24
Network Security Auditing
■
Statistical sampling of data transaction.
■
Run security analysis tools to verify technical control effectiveness.
Data Analysis Phase: Analyze, Map, and Recommend After the auditor has gathered all of the evidence, the next phase involves analyzing what is discovered. This analysis requires an auditor’s experience and professional knowledge to determine how to prioritize any deficiencies identified. If the audit is done in response to regulatory compliance requirements or industry standards, then the auditor should also map the observed controls to the applicable standard or law to identify if anything is missing or incomplete. Finally, most audits also have an opinion component where the auditor must state his professional opinion regarding the effectiveness of the organization’s controls, and recommend solutions about how to improve the quality of the control to reduce risk. The actions in this phase are: ■
Categorize and identify evidence gathered during the audit.
■
Analyze policies and procedures for effectiveness.
■
Prioritize risks and rank according to severity.
■
Map identified controls to industry standards or regulatory compliance requirements.
■
If required, make recommendations on policy, procedure, and technology improvements.
Audit Report Phase: Write, Present, and File the Audit Report Authoring the audit report and presenting it to management is one of the most critical phases of the audit. Articulating the deficiencies found and recommendations about how to reduce risk are the primary reasons why the auditor is engaged in the first place. The report should include an executive summary and detailed findings about how the deficiencies discovered apply to the business. The report should not just be the output from a Nessus scan, but actually clarify why a particular vulnerability is determined to be critical or low risk. Recommendations about how to address each audit exception should also be included. The auditor shouldn’t just drop off a stack of papers but also present the findings in a meeting between management, the auditor, and key stakeholders. This gives the auditor a chance to clarify findings and answer questions that might arise as the organization digests the audit report. After the report has been presented, the final work papers should be filed as proof of the audit. Auditing is not just about showing that you understand what needs to be done; it’s also about proving it! This phase includes: ■
Create a clear and concise report detailing risk.
■
Write an executive summary that highlights critical items.
■
Present the audit findings to management and key stakeholders.
■
Develop solutions to address audit exceptions.
■
Provide all documentation and evidence to be filed by the organization.
Chapter 1: The Principles of Auditing 25
Follow-Up Phase: Follow up, Follow up, Follow up! After the report is filed, that’s it, right? Not quite. It is important to understand that an audit is a snapshot in time. The deficiencies found need to be addressed and should be remedied as soon as possible after the audit occurs. An auditor might be called back after the organization has had a chance to remediate the deficiencies so that the auditor can reexamine the new controls or process. This gives the auditor a chance to get feedback on the solutions chosen. To prevent a conflict of interest, auditors are not generally involved in fixing the deficiencies. This helps to keep the auditor neutral to the situation so that he can be objective and unbiased.
Summary This chapter covered some of the fundamental aspects of auditing. Providing a risk-based auditing approach that leverages industry standards and best practices is an integral part of a company’s IT Governance strategy. You can’t protect what you don’t know about. Auditing gives an organization the opportunity to test assumptions about how secure its assets and data are. In summary: ■
The five pillars of security—assessment, prevention, detection, reaction, and recovery—define the process of security.
■
The building blocks of a security strategy are policy, procedures, and standards. Policy is where security strategy is set, whereas procedures and standards provide guidance about how to accomplish the policies’ objectives.
■
Security controls are how an organization prevents, detects, corrects, and recovers from an incident. Many types of controls work together to build a defensive strategy. Building a control table can identify weaknesses in security posture.
■
Risk management isn’t just a recommended practice; SOX, HIPAA, and GLBA require it. Assessing risk provides the justification and prioritization necessary to invest time, money, and resources for the areas of security that are critical to the success of the business.
■
Auditing is a process and has different degrees and depth. The scope of an audit defines whether or not you conduct a review, assessment, or full audit. The role of the auditor is to report on control deficiencies and risk.
26
Network Security Auditing
References in This Chapter Cole, Eric. Network Security Bible, First Edition. John Wiley & Sons, 2006. Schneier, Bruce. Secrets & Lies: Digital Security in a Networked World. John Wiley & Sons, 2004. Bejtlich, Richard. The Tao of Network Security Monitoring Beyond Intrusion Detection. Addison Wesley, 2004. Landoll, Douglas J. The Security Risk Assessment Handbook: A Guide for Performing Security Risk Assessments. Auerbach Publications, 2006. Peltier, Thomas R/Peltier, Justin. Complete Guide to CISM Certification. Auerbach Publications, 2007. Slade, Robert M. Information Security Management Handbook, Fifth Edition, Vol 3. Auerbach Publications, 2006. Schwartau, Winn. Time-Based Security. Interactive Press, 1999. SANS Institute, The SANS Security Policy Project, http://www.sans.org/resources/policies/#question
Chapter 2
Information Security and the Law
Information security law is one of the key drivers of auditing in businesses today. Most companies agree that auditing security is a good idea, but actually doing it on a regular basis requires a commitment of resources and time that could easily be set aside for other projects. After a long string of high-impact security failures in business, security has shifted from a voluntary discipline to one that is required by law. Compliance to federal and state laws is enforced through fines, and, in some cases, jail time. In addition, the payment card industry created standards that address security requirements for anyone who processes credit cards as part of a business. If you don’t comply, you can’t accept credit cards and can face fines. For these reasons, auditors are tasked with identifying weaknesses in policy, procedure, and technology to determine whether a company meets the security requirements set forth by industry standards and law. To do this, auditors should have some knowledge of law as it pertains to information security and the penalties for noncompliance. The purpose of this chapter is to present some common IT security laws and regulations that have an impact on network security. It is important to note that this chapter was written in 2010, and the laws and their interpretation may have changed drastically between the time this book was published and when you read it. This chapter is not meant to represent legal counsel in any way, and you are encouraged to check with an attorney for specific recommendations about laws that might apply to your company.
IT Security Laws Technology and law sometimes have a hard time working together. Law is by its nature conservative because it strives to create a consistent basis for identifying right and wrong. The speed of technological advances makes it difficult for law and law makers to keep up. Many of the laws enacted over the past few years have been reactions to major events such as Enron, Choicepoint, or Heartland Payment Systems. These painful reminders of the impact of lax security have acted as a catalyst for law makers to take a
28
Network Security Auditing
tougher stance on computer-enabled crimes because of the significant monetary loss and potential consequences to the average person. No one would argue that computers are used to commit crimes and our legal system and law enforcement professionals are dropped into the deep end of advanced technologies where hackers and criminals can hide behind the anonymity that the Internet affords. Awareness of the law can help ensure that a business follows the rules and builds controls in a way that provides law enforcement the evidence needed to detect crimes and prosecute criminals. The term Cyberlaw has been coined as a means to describe law that pertains to the Internet and computer-related legal issues. This area of the law continues to change dramatically as lawmakers try to grapple with applying laws to protect people from criminals who have moved to the Internet in mass. To put the laws into perspective, it helps to understand the evolution of Cyberlaw. Network computing in the early 1980s generally consisted of plugging your “blazing fast” 300-baud modem into the back of your Commodore Vic 20 and dialing out to your local bulletin board systems or Compuserve. The bulletin board system era of the 1980s helped to connect millions of individuals interested in computers. While legitimate computer enthusiasts ran most BBSs, others, of the less ethically constrained sort, formed the beginnings of the pirate software scene and created a place to go to share information and techniques about how to exploit other computers. Long-distance toll fraud was rampant, and law enforcement started to take a serious look at what to do with this new area of criminal activity. Of course, 1983 also brought us the movie Wargames, which not only introduced the world to the previously clandestine hacker community, but also showed a frightening scenario of what could happen if a “hacker” got access to a super secret government computer system. (I wonder how many IT security careers this movie started?) Companies and government agencies were already feeling the effects of hackers on their systems, but with courts limited to using a set of statutes that were focused on physical loss of property and mail fraud, it was difficult to prosecute unauthorized computer access as a crime because nothing was technically “missing.” In 1978, the state of Florida led the way with the first statute to assist in prosecuting computer theft and hacking, but unless you lived in or committed a computer crime in Florida, the law did not apply to you. In 1984, the United States Congress passed the first federal computer statute (18 U.S.C. § 1030), making it illegal to gain unlawful entry to a federal or financial institutions computer system. This statute was further amended in 1986 and became the Computer Fraud and Abuse Act, which criminalized unauthorized access, damage, fraud, or destruction of data belonging to others. The global ubiquity of the Internet and the pervasive use of computers by companies to conduct business is why federal statues have such relevance to computer crimes. Congress has the right to create laws to regulate interstate and foreign commerce. 18 U.S.C § 1030 has provisions that identify a “protected computer” as a computer that “is used in interstate or foreign commerce or communication, including a computer located outside the United States that is used in a manner that affects interstate or foreign com-
Chapter 2: Information Security and the Law
merce or communication of the United States.” “Used in interstate commerce” covers just about any computer connected to the Internet because you can use that computer to buy or sell goods and services across state lines. Today, there is a wide array of computerrelated laws from a federal and individual state level, making them difficult to keep up with. There is simply no substitute for legal council in helping to navigate through them.
Hacking, Cracking, and Fraud Laws Hacking, cracking, and fraud are areas of the law that attackers break when attempting to gain unauthorized access to the network. As mentioned in Chapter 1, “The Principles of Auditing,” the only real difference between a hacker and an auditor is the permission afforded by the auditing charter or engagement letter. During the course of security testing, an auditor would be in violation of a number of these laws if he did not have authorization to conduct assessment activities. This section is intended to give an auditor a basic understanding of the laws that govern technical security testing to ensure that awareness of the importance of gaining permission before testing. Although an auditor is not law enforcement, he does have an obligation to report potentially illegal activities. This knowledge can help auditors identify questionable activities that they might uncover during an audit.
Computer Fraud and Abuse Act The Computer Fraud and Abuse Act (18 U.S.C § 1030) has undergone many changes throughout the years as Congress struggles with the pace of technology proliferation and misuse. The Identity Theft Enforcement and Restitution Act of 2008 is the most recent modification to the provisions of this law. The CFAA is one of the more important statutes because it covers the “breaking-and-entering” aspect of computer criminal law. A digital intruder is identified by this law as someone who accesses an electronic system “without authorization.” As an auditor, you can avoid violating the CFAA by making sure that you have full authorization, in writing, before conducting any type of auditing engagement. The statute has seven primary provisions and covers a wide variety of computer crimes. Each of the seven provisions specifies access without authorization or escalation of privileges as a prerequisite and then includes specific instances of what an individual did while connected. Most criminal computer activity runs afoul of this law because it isn’t just concerned with the breaking and entering of a computer system, but also the release of Malware (virus, worms, trojans, and so on), password cracking, and extortion through denial of service or theft. Section 1030 (a)(5)(B) provides the capability to prosecute for reckless and negligent behavior, which means that someone can’t simply argue that he didn’t understand what the blinking red “kill remote system” button on his hacking tool would do. Table 2-1 provides a summary of the provisions of this law.
29
30
Network Security Auditing
Table 2-1
Summary of Computer Fraud and Abuse Act
§ 1030 Offense
Description
Penalty
(a)(1)Obtaining National Security Information
Knowingly accessing a computer without authorization to obtain, transmit, or retain national security information that could harm the United States
Fine and/or 10 years 20 years second offense
(a)(2)Compromising the Confidentiality of a Computer
Intentionally hacking into a computer to stealing financial records from any protected computer
Fine and/or 1–5 years
(a)(3)Trespassing in a Government Computer
Intentionally hacking into a nonpublic U.S. computer without authorization
Fine and/or 1 year 10 years second offense
(a)(4)Accessing a Computer to Defraud & Obtain Value
Knowingly accessing a protected computer without authorization to commit fraud or obtain anything of value, including use of the computer greater than $5,000
Fine and/or 5 years 10 years second offense
(a)(5)(A)Knowingly Transmission of Code Program, Information, or Command and Cause Intentional Damage to Computer
Purposely breaking into a computer through automated or manual means resulting in loss
Fine and/or 10 years 20 years or life second offense
(a)(5)(B) Intentional Access Without Authorization and Caused Reckless Damage
Fine and/or Purposely breaking into a computer 5 years 20 through automated or manual means and negligently causing damages resulting years second offense in loss of $5,000 or more during 1 year OR Modifying the medical care of a person OR Causing physical injury OR Threatening public health or safety OR damaging government computers OR Causing or attempting to cause death OR Causing damage to 10 or more computers in a year
(a)(5)(C)Intentional Access Without Authorization Causing Damage and Loss
Purposely breaking into a computer through automated or manual means without authorization and causing damage resulting in loss
Fine and/or 1 year 10 years second offense continues
Chapter 2: Information Security and the Law
Table 2-1
Summary of Computer Fraud and Abuse Act (continued)
§ 1030 Offense
Description
Penalty
(a)(6)Trafficking in Passwords
Selling or exchanging passwords or other access information with the intent to defraud, affecting interstate or foreign commerce
Fine and/or 1 year 10 years second offense
(a)(7)(A)Extortion Involving Threats to Damage Computer
Attempting to extort money or anything Fine and/or 5 years else of value containing a threat to 10 years secdamage a protected computer system ond offense
(a)(7)(B)Stealing Confidentiality Information
Attempting to break into a computerprotected computer system to steal confidential information
Fine and/or 5 years 10 years second offense
(a)(7)(C)Extortion of Money for Not Damaging a Protected Computer
Demanding or requesting money or another thing of value in exchange for not damaging a protected computer
Fine and/or 5 years 10 years second offense
Access Device Statute 18 USC § 1029, the Access Device Statute (often referred to as the Credit Card statute), prohibits criminal activities relating to any identification mechanism that can be used to gain access to bank accounts, credit cards, or telecommunication services. This is a broad statute and covers ten individual activities ranging from the creation of fake credit cards to password cracking. Access devices defined by this law include “any card, plate, code, account number, electronic serial number, mobile identification number, personal identification number, or other telecommunications service, equipment, or instrument identifier, or other means of account access.” Credit card theft and the trafficking of credit card information is a big business for criminals. Phishing is one of the most common techniques used to get a victim to divulge credit card information, account numbers, and passwords through real and legitimate looking e-mails that redirect the user to fake websites that also look almost identical to the legitimate website they are imitating to harvest information. Many of these bogus websites act as proxies for the real banking site and silently record all of the information a person enters as he goes about online transactions. These are examples of crimes punishable under the Access Device Statute. Auditors who are asked to assess password security typically run a cracking program to brute-force passwords. This activity can violate this statute. All password auditing should be approved and authorized before testing. The access device statute enables for prosecution of those who steal passwords or credit card numbers. Keystroke logging software
31
32
Network Security Auditing
and other password- or pin-stealing technology should be reported by the auditor as its presence might fall under this federal statute. A summary of 18 USC § 1029 is shown in Table 2-2. Table 2-2
Summary of 18 USC 1029 Access Device Statute
§ 1029 Offense
Description
Monetary Loss/Damages
Penalty
(a)(1)Counterfeit Access Devices
Knowingly and with the intent to defraud Produces, uses, or traffics in one or more counterfeit access devices Affecting interstate commerce
No loss required
Fine and/or 10 years Fine and/or 20 years for second offense
Must obtain $1,000 (a)(2)Unauthorized Knowingly and with intent to or more in value Access Devices defraud Uses or traffics in one or more unau- during 1 year thorized access devices during any 1-year period Obtaining at least $1,000 in value during same 1-year period Affecting interstate or foreign commerce
Fine and/or 10 years Fine and/or 20 years for second offense
No loss required
Fine and/or 10 years Fine and/or 20 years for second offense
No loss required (a)(4)Access Device Knowingly and with intent to Making Equipment defraud Produces, traffics in, has control or custody of, or possesses Accessing device-making equipment Affecting interstate or foreign commerce
Fine and/or 10 years Fine and/or 20 years for second offense
(a)(3)Possession of Knowingly and with intent to Access Device defraud Uses or traffics in One or more unauthorized access device(s) During any 1-year period Affecting interstate or foreign commerce
continues
Chapter 2: Information Security and the Law
Table 2-2
Summary of 18 USC 1029 Access Device Statute
(continued)
§ 1029 Offense
Description
Monetary Loss/Damages
(a)(5)Misuse of Access Device Issued to Another
Knowingly and with intent to defraud Causing transactions to receive at least $1,000 of value During any 1-year period Using one or more access device(s) issued to another person Affecting interstate or foreign commerce
$1,000 or more loss in 1 year
Penalty
Fine and/or 10 years Fine and/or 20 years for second offense
No loss required (a)(6)Solicitation to Knowingly and with intent to Offer or Sell Access defraud Soliciting a person for the Devices purpose of offering an access device OR Soliciting a person for the purpose of selling information regarding an access device or applying to obtain an access device Without the authorization of the issuer of the access device
Fine and/or 10 years Fine and/or 20 years for second offense
(a)(7)Modified or Altered Telecommunication Devices
No loss required Knowingly and with intent to defraud Uses, produces, traffics in, has control or custody of, or possesses a telecommunication instrument that has been modified or altered to obtain unauthorized use of telecommunication services Affecting interstate or foreign commerce
Fine and/or 10 years Fine and/or 20 years for second offense
(a)(8)Scanning Receivers
Knowingly and with intent to defraud Uses, produces, traffics in, has control or custody of, or possesses a scanning receiver Affecting interstate or foreign commerce
No loss required
Fine and/or 15 years Fine and/or 20 years for second offense
continues
33
34
Network Security Auditing
Table 2-2
Summary of 18 USC 1029 Access Device Statute
(continued)
§ 1029 Offense
Description
Monetary Loss/Damages
(a)(9)Phone Phreaking
No loss required Knowingly and with intent to defraud Uses, produces, traffics in, has control or custody of, or possesses hardware or software configured to insert or modify telecommunicationidentifying information so that the telecommunications instrument might be used to obtain unauthorized service Affecting interstate or foreign commerce
Penalty
Fine and/or 15 years Fine and/or 20 years for second offense
Electronic Communications Privacy Act Mention the word wiretap, and memories of movies with government agents sitting in a nondescript delivery van with surveillance equipment listening in on telephone calls probably comes to mind. Of course, today, there are fiber optic cables delivering converged voice, video, and data at the equivalent of DS3 speeds to your house. That makes listening in on your conversation with grandma a lot harder than connecting a set of alligator clips to the telephone pole outside your house. The Wiretap Act, which first came into law in Title III of the Omnibus Crime Control and Safe Streets Act of 1968, was created to punish the unauthorized access of wire and oral communication. This law became less relevant as more and more communications became digitized, and the use of e-mail became widespread. In 1986, Congress enacted the Electronic Communications Privacy Act (ECPA) to broaden the reach of the Wiretap Act and to cover newer forms of electronic communications. The ECPA consists of a series of statues that are broken down into three main sections (or titles). Title I: Wiretap Act covers the interception of wire, oral, and electronic communications while in transit, and it can be found in 18 USC §§ 2510-2522. Title II: Stored Communications Act protects communications stored electronically, such as e-mail or voicemail, and can be found in 18 USC §§ 2701-2712. Title III: Pen/Trap Statute, which is addressed in 18 USC §§ 3121-3127, regulates the use of pen register and trap/trace devices that are used to record phone numbers dialed, call routing, and signaling information that determines where a caller is or who it called.
Title I: Wiretap Act The primary purpose of the Wiretap Act is to prohibit unauthorized individuals or law enforcement (without a warrant) from eavesdropping or disclosing oral or electronic com-
Chapter 2: Information Security and the Law
munications. This applies to any communications, but specifically to computer networks, by making it illegal to install an unauthorized sniffer program. The key aspect of these statutes is to protect communications in transit or real-time communication, meaning that unless the communication is in motion (transmitted on the wire), it is not protected under this statute. The fact that the Wiretap Act was applicable only to real-time communications is why the Stored Communications Act was created (it is covered in the next section). There are a significant number of exceptions to the prohibitions against eavesdropping, as outlined in the statutes that make up the Wiretap Act. The most relevant to network security are when one of the parties communicating consents to monitoring, where the service provider (the term service provider applies to business networks too) monitors the network to combat fraud and service theft, when monitoring computer trespassers, and when the system being accessed is a publicly available system (such as an Instant Message chat room). The following list summarizes the four primary exceptions to the Wiretap Act: ■
Consent exception: This exception requires that one party has consented to communication interception. Login banners or terms of service that inform a user that his communications will be monitored should be displayed whenever possible. To help protect itself, a company must give notice to employees via a written electronic communications policy detailing that all communications are subject to monitoring. It is also highly encouraged to require a signed (physical or electronic) consent to monitoring document.
■
Provider exception: The provider exception enables operators of communication services to monitor the use of their equipment in the course of conducting business for the purposes of protecting data and assets. This exception gives a company the capability to monitor communications on its networks via intrusion detection systems, packet capture tools, or other technologies that combat fraud and misuse.
■
Computer trespasser exception: This exception is intended to enable victims of a computer crime to authorize law enforcement to monitor communications when under attack. The exception does not give someone the right to intercept third-party communications without being directed by or in conjunction with law enforcement. A company should never attempt to investigate a crime without engaging law enforcement authorities.
■
Accessible to the public exception: Communications posted to open systems such as chat rooms, web forums, or blogs are not protected under the ECPA. If it is easily accessible to the public and nonprivate, then it may be monitored.
The Wiretap Act gives companies the legal authority to protect their assets by actively inspecting for fraud and abuse on their networks, making it perfectly legal to deploy full packet capture tools and IDS/IPS technologies. As auditors, it is important to ensure that a solid network inspection policy exists that is consistently enforced and all users are aware of it through login banners and documented, ongoing awareness training.
35
36
Network Security Auditing
Table 2-3 provides a summary of 18 USC § 2511. Table 2-3 Summary of 18 USC 2511 Interception of Wire, Oral, or Electronic Communication Prohibited § 2511 Offense
Description
Penalty
(1)(a)Illegal Wiretaps
Except as authorized (service provider, consent, or law enforcement with warrant) Intentionally intercepting, endeavoring to intercept, or procuring another to intercept or endeavor to intercept Any wire, oral, or electronic communication
Fine and/or 5 years
(1)(b)Illegal Wiretaps
Except as authorized (service provider, consent, or law enforcement with warrant) Intentionally using, endeavoring to use, or procuring another to use or endeavor to use any electronic, mechanical, or other device to intercept any oral communication If the device is affixed to or transmits signals through a wire communication connection; or, if the device transmits communications by radio or interferes with a radio transmission; or, if the device is reasonably known to have been sent through interstate or foreign commerce; or, if such device is used or endeavored to be used on the premises of a business whose operations affect interstate or foreign commerce; or, if such device obtains or is for the purpose of obtaining information relating to the operations of any business whose operations affect interstate or foreign commerce
Fine and/or 5 years
(1)(C)Disclosing Contents of Illegal Wiretap
Except as authorized within the statute (for example, Fine and/or 5 service provider exception, consent exception, law years enforcement Title III or Pen/Trap & Trace orders) Intentionally discloses or endeavors to disclose the contents of any wire, oral, or electronic communication Knowing or with reason to know that the information was unlawfully intercepted continues
Chapter 2: Information Security and the Law
Table 2-3 Summary of 18 USC 2511 Interception of Wire, Oral, or Electronic Communication Prohibited (continued) § 2511 Offense
Description
Penalty
(1)(D)Using Contents of an Illegal Wiretap
Except as authorized within the statute (for example, Fine and/or 5 service provider exception, consent exception, law years enforcement Title III or Pen/Trap & Trace orders) Intentionally uses or endeavors to use the contents of any wire, oral, or electronic communication Knowing or with reason to know that the information was unlawfully intercepted
(1)(E)Disclosing Authorized Government Wiretap in Order to Obstruct Justice
Intentionally discloses or endeavors to disclose the contents of any wire, oral, or electronic communication Lawfully obtained by the government (for example, under Title III, FISA, and undercover operations) Intending to obstruct, impede, or interfere with an authorized criminal investigation, knowing that the information was obtained in a criminal investigation, and having received the information in connection with a criminal investigation
Fine and/or 5 years
Title II: Stored Communications Act The Stored Communications Act was implemented to protect e-mail and voicemail from unlawful access. The Wiretap Act protects communications in transit, but does not protect the privacy of a message in storage or on a mail server waiting to be retrieved by the intended recipient. 18 USC § 2701 criminalizes illegally obtaining, altering, or preventing access to a communication in electronic storage. The law also provides felony charges for stealing communications to be used for commercial advantage, malicious destruction, or to further a criminal act. To be protected under this act, an electronic communication service that consists of voicemail or e-mail must be present, which means that a client’s individual computer or home computer that received e-mail or voice mail does not apply because the client computer does not provide e-mail services to others. There are several exceptions to the law: ■
Service provider exception: This law does not apply to “the person or entity providing a wire or electronic communication service: regardless of their motives in accessing stored communication”. A business can inspect any e-mail or voicemail residing on systems and not violate the law. A written policy explaining that e-mail and voicemail can and will be monitored is also recommended.
37
38
Network Security Auditing
■
Authorized use exception: A user of the communications system can authorize others to access stored communications. This happens when employees go on vacation or have administrative assistants who handle scheduling and correspondence and are therefore excluded from this statute.
■
Court order exception: There are numerous exceptions specifically mentioned in the statute about dealing with a court order to provide relevant evidence in the form of email or voicemail. They are listed in section 2703, 2704, and 2518 (Wiretap Act).
Table 2-4 provides a summary of 18 USC § 2701-2712. Table 2-4 Summary of 18 USC 2701 Stored Wire and Electronic Communications and Transactional Records Access § 2701 Offense
Description
Penalty
Accessing Voice Mail or E-mail
Obtaining, altering, or preventing authorized access to unopened voice mail and unopened e-mail by intentionally accessing without authorization a facility through which an electronic communication service is provided, or intentionally exceeding authorized access to that facility
2 years and fine for repeat offense under 2701, if committed for purposes of commercial advantage, malicious destruction or damage, or private commercial gain 1 year and fine for first offense, if committed for purposes of commercial advantage, malicious destruction or damage, or private commercial gain 6 months and fine if not committed for purposes of commercial advantage, malicious destruction or damage, or private commercial gain
Title III: Pen/Trap Statute A pen register is a device that reads the routing information as a telephone dials a number, and a trap and trace device records incoming caller information. This statute was originally written to regulate monitoring telephone-calling information, but has been expanded to include additional applications in network communications. The Patriot Act modified much of the wording to include other methods of communication beyond just the telephone system. Because the law was written to include “an instrument or facility from which a wire or electrical communication is transmitted,” an enormous amount of network services are included. In fact the law includes protection for e-mail addresses, user accounts, instant messaging clients, and virtually any communication that has a source and destination. This includes many of the tools used by auditors to test security controls. Because an IP packet has both a source and destination address, a sniffer qualifies as a pen/trap device. The primary purpose of this statute is to ensure that law enforcement has a court order before it puts these types of monitoring devices into use. The law also enables businesses to implement these types of tools at will without a court order under the following conditions:
Chapter 2: Information Security and the Law
■
Any activity related to the operations and maintenance of the network services or to protect users from abuse or illegal activities
■
Recording connection information (IP address, headers, and so on) to protect assets and users
■
When consent is given for monitoring as part of an acceptable use policy or terms and conditions of service
Table 2-5 provides a summary of 18 USC § 3121-3127. Table 2-5
Summary of 18 USC 3121 Pen Registers and Trap and Trace Devices
§ 3121 Offense
Description
Penalty
Prohibition on Pen Register and Trap and Trace Device Use
No person may install or use a pen register or Up to 1 year in a trap and trace device without first obtaining prison and/or fine a court order.
Intellectual Property Laws This section covers two of the most relevant intellectual property statutes that auditors can run into in the course of performing an audit. The Digital Millennium Copyright Act and Economic Espionage Act are laws that are intended to protect and criminalize the theft of intellectual property and prevent the circumvention of protection controls. As part of a security assessment, auditors might have to break protection controls and possibly discover incidents of proprietary information being removed by employees or unscrupulous business partners. Knowledge of these laws is valuable for auditors staying out of trouble and identifying potentially illegal activity.
Digital Millennium Copyright Act Copyright protection has always been a challenge in the digital world. For many people, the theft of software, music, and movies doesn’t seem as tangible as walking into a convenience store and stealing a gallon of milk. Use of the Internet and peer-to-peer file sharing forever changed the landscape of copyrighted content and control. To address the dangers of copyright infringement on the Internet, Congress approved the Digital Millennium Copyright Act as a means to combat online piracy, distribution of copyrighted works, and the circumvention of access controls. When the Digital Millennium Copyright Act (17 U.S.C. § 1201, 1202, and 1204) was signed into law October 28, 1998, many felt that it was entirely too strict and stifled research and fair use of software. From a security researcher’s standpoint, it seemed to be a signal to find another job, as much of what a security researcher does requires breaking access controls or other protection mechanisms in software. Fortunately, there have been a number of exemptions created to address these and a few other special case situations. Following are the exceptions most applicable to computer security professionals:
39
40
Network Security Auditing
■
Software interoperability: To get an application or piece of software to interoperate (exchange information) with existing software, it is permissible to circumvent access controls to portions of a program. The sole purpose for doing this must be for interoperability. The methods used to create interoperability can be shared as long as the information does not constitute copyright infringement or break any other laws.
■
Protection of personal information: It is not illegal to disable spyware or other software that records personal information if the software does not allow someone to turn off those capabilities. Circumventing this type of activity is permissible as long as it does not affect any other function of the software application.
■
Encryption research: Encryption research is defined as “activities necessary to identify and analyze flaws and vulnerabilities of encryption technologies applied to copyrighted works, if these activities are conducted to advance the state of knowledge in the field of encryption technologies or to assist in the development of encryption products.” Under the DCMA, the researcher must purchase or lawfully obtain the encrypted copyrighted work—breaking the encryption is a necessary part of research, the researcher made a good faith attempt to get permission from the copyright owners, and breaking the encryption does not violate any other laws.
■
Security testing: The DMCA defines security testing as “accessing a computer, computer system, or computer network, solely for the purpose of good faith testing, investigating, or correcting, a security flaw or vulnerability, with the authorization of the owner or operator of such computer, computer system, or computer network.” The key to the exception is that the person conducting security testing is authorized to do so by the owner of the system under the test. This exception also allows for the release of technological tools to conduct these types of security tests as long as they do not utilize copyrighted information.
Table 2-6 provides a summary of the DMCA. Table 2-6
Summary of DMCA
DMCA Offense
Description
§ 1201 Circumvention A prohibition on circumventing access controls of Copyright An access control circumvention Protection Systems device ban (sometimes called the “trafficking” ban) A copyright protection circumvention device ban § 1202 Integrity of Copyright Management Information
Penalty Commercial gain: The first offense is $500,000 and/or 5 years, and the second offense is a $1,000,000 fine and/or 10 years. Civil fines up to $2,500 or $25,000 per violation.
A prohibition on the removal of Commercial gain: The first offense copyright management informa- is $500,000 and/or 5 years, and the second offense is a $1,000,000 fine tion and/or 10 years. Civil fines up to $2500 or $25,000 per violation.
Chapter 2: Information Security and the Law
Economic Espionage Act The Economic Espionage Act of 1996 criminalizes the theft of commercial trade secrets. The law has two primary sections with 18 USC § 1831 focused on theft of trade secrets from U.S. companies for the benefit of foreign governments and 18 USC § 1832 focused on theft between companies in the United States. Both sections punish someone who steals proprietary information in any form. This theft can be physical or through making copies of files, memorizing formulas, taking pictures, uploading or downloading data, or any other method of getting information someone is not authorized to have or sell. A large majority of these cases seem to involve insiders who have tried to sell information from their companies or who took information to another company after leaving. The area that is most important for auditors and computer security in general is that in order to prosecute someone under this law, the company must be able to show where it has followed “reasonable measures” to maintain the information’s secrecy. Properly securing key assets and information should be a top priority for any organization. Information like the prototype for a new widget that is expected to make the company millions of dollars might not qualify as a trade secret if it is left in a folder on a file server that anyone in the company can access. Table 2-7 provides a summary of the EEA. Table 2-7
Summary of Economic Espionage Act
Offense
Description
Penalty
15 years and $500,000 § 1831 Electronic Without authority takes, copies, or alters a trade For organizations, fine Espionage Act secret, or fraudulently obtains a trade secret, or knowingly obtains a stolen or improperly obtained up to $10,000,000 trade secret, or attempts or conspires to do the same Intending or knowing that a foreign government, foreign instrumentality, or foreign agent will thereby benefit § 1832 Trade Secrets Act
10 years and fine Without authority, takes, copies, or alters a trade For organizations, fine secret, or fraudulently obtains a trade secret, or knowingly obtains a stolen or improperly obtained up to $5,000,000 trade secret, or attempts or conspires to do the same Intending or knowing that the trade secret owner will be injured With intent to convert a trade secret that is related to or included in a product produced for or placed in interstate or foreign commerce To the economic benefit of anyone other than the trade secret owner
41
42
Network Security Auditing
CAN-SPAM Act of 2003 Leave it to those wacky members of Congress to think up a name like CAN-SPAM for the nation’s first law restricting SPAM e-mail (and you thought politicians didn’t have a sense of humor). CAN-SPAM stands for Controlling the Assault of Non-Solicited Pornography and Marketing Act, and although it doesn’t prevent SPAM, it does put in place penalties for spammers and the businesses that advertise through SPAM messages. The law also charges the Federal Trade Commission (FTC) as the primary enforcement agency and allows for other federal and state agencies to assist if required. There are five primary areas addressed by the CAN-SPAM Act: ■
Unauthorized access of a computer system: Criminalizes hacking into a computer for the purposes of sending multiple SPAM messages through it.
■
Unauthorized use of e-mail relays: A number of years ago, spammers would use the default settings of e-mail systems to forward e-mail they received and not just from the e-mail domain that they provided mail services for; system administrators have corrected this error, so spammers rely on malware that is used against vulnerable computers to allow a would-be spammer to utilize an infected PC to send spam and hide the spammer’s identity.
■
Bans fake or misleading e-mail headers: A common practice of spammers is to fake the e-mail source address to try to hide the source of the messages. The E-mail From field must properly identify the sender.
■
Bans creation of fake e-mail accounts and domain names for SPAM: The law bans the creation of five or more e-mail addresses or two or more domain names using falsified registration data for the purposes of sending SPAM e-mail. It is also illegal to use scripts or other automated tools for mass registering for e-mail addresses.
■
Bans registering for IP addresses for sending SPAM: Criminalizes registering for five or more IP addresses with false identification so that multiple SPAM messages can be sent.
Although the bulk of these provisions are intended to identify obvious spammers, it is important that businesses realize that they can be classified as a spammer if they don’t follow the rules of the CAN-SPAM Act. Many companies use e-mail blasts or mass mailing as a marketing tool, which is perfectly legal, if the company adheres to the following requirements: ■
Clearly identify that the message is a commercial advertisement or solicitation.
■
Provide for an opt-out mechanism that gives the recipient the ability to decline any further e-mail messages. The sender has 10 days to remove the user from subsequent mailings.
■
A valid postal address of the sender.
■
Do not use tools that “harvest” or automatically gather e-mail addresses from websites or forums that have published notices that prevent this activity.
Table 2-8 provides a summary of the CAN-SPAM Act.
Chapter 2: Information Security and the Law
Table 2-8
Summary of the CAN-SPAM Act
Offense Description § 1037 CANSPAM Act
Penalty
(1) Accesses a protected computer without Forfeiture of equipment used and/or authorization, and intentionally initiates the money earned transmission of multiple commercial elec- Fine and/or 1 year tronic mail messages from or through such OR Fine and/or 3 years if: computer, • Unauthorized access to a computer to (2) Uses a protected computer to relay or send spam retransmit multiple commercial electronic mail messages, with the intent to deceive or • Involves 20 or more fake e-mail or account registrations or 10 or more mislead recipients, or any Internet access fake domain name registrations service, as to the origin of such messages, (3) Materially falsifies header information in • E-mail messages transmitted exceed 2,500 during any 24-hour period, multiple commercial electronic mail mes25,000 during any 30-day period, or sages and intentionally initiates the trans250,000 during any 1-year period; mission of such messages, (4) Registers, using information that materi- • Caused loss of $5,000 during 1-year period ally falsifies the identity of the actual regis• Obtained anything of value of $5,000 trant, for five or more electronic mail or more during any 1-year period accounts or online user accounts or two or more domain names, and intentionally initi- • Defendant was in a position of organizer or leader ates the transmission of multiple commercial electronic mail messages from any combination of such accounts or domain names, or (5) Falsely represents oneself to be the registrant or the legitimate successor in interest to the registrant of five or more Internet Protocol addresses, and intentionally initiates the transmission of multiple commercial electronic mail messages from such addresses
State and Local Laws Many of the federal laws that have been covered started at the state level. Although federal laws provide the greatest reach in prosecuting criminals, state laws can add extra penalties in areas not covered at the federal level. A significant portion of U.S. laws addressing current crimes and Internet annoyances are addressed by the states, as Internet crime and privacy have become a major topic for debate. The states are usually able to enact laws much quicker than Congress and can address the misuse of new technologies. For instance, 32 states have laws that ban computer-assisted, remote-controlled hunting over the Internet. Privacy and identity theft are the two issues most likely to be discussed, but
43
44
Network Security Auditing
the states are active in addressing many of the crimes committed on the Internet. Following is a list of some of the most recent state laws: ■
Cyber-stalking: Forty-seven states have included laws against using electronic communications to threaten, harass, or stalk someone on the Internet.
■
Hacking and unauthorized access: All 50 states have specific legislation criminalizing hacking, cracking, and unauthorized access to computer networks.
■
Virus laws: Twenty-seven states have laws against releasing viruses, worms, or other malware with the intention of destroying, modifying, recording, or disrupting information stored on a computer system.
■
Electronic surveillance: All 50 states (Vermont being the exception) include protection from unauthorized surveillance; 31 of the states specifically mention or have statues regarding interception of computer traffic.
■
Phishing: Twenty-one states have laws against transmitting unsolicited e-mail messages pretending to be from legitimate companies or banks with the intent of tricking someone into divulging personal information.
■
Spyware: Spyware is software that is loaded surreptitiously on a user’s computer and is used to track a person’s activity, collect personal information, or deliver popup messages advertising products. Anyone who has been on the Internet is well aware of this type of computer annoyance. Four states have enacted anti-adware and spyware legislation with limited success. The challenge is in defining what constitutes illegal spyware and adware, but the states are trying to make a difference.
■
Breach of information: Although California gets credit for having the most widely known security breach notification law—Senate Bill 1386—45 other states have enacted laws requiring companies to notify customers in the event that the customers’ personal information has been compromised.
Reporting a Crime In the course of auditing a network, there is real potential for an auditor to uncover illegal activities. It is always important to work through management whenever something is uncovered that looks suspect, as most auditors are not trained law enforcement investigators. After a potential illegal act is identified, the auditor might be asked for advice about to do next. There is a lot of confusion about who to call, especially with crimes that might occur over the Internet where the criminal can be anywhere on the Earth. Who to call depends on the scope of the crime and the dollar value of the incident. Six federal law enforcement agencies investigate Internet and computer-related crimes: the Federal Bureau of Investigations (FBI), the United States Secret Service, the Bureau of Alcohol Tobacco and Firearms (ATF), the United States Customs Services, the FTC, and the United States Postal Inspection Services.
Chapter 2: Information Security and the Law
The FBI and the Secret Service, however, are the two primary organizations from a federal perspective that are charged with investigating computer crime. As a general rule, the FBI and Secret Service tend to not investigate crimes under $1,000. It is important to identify damages when reporting a crime, such as the cost of lost service, employee labor costs, consultant time, and other directly related expenses because the severity of the crime directly impacts whether or not federal agencies can devote resources to investigate the incident. Most people are familiar with the Secret Service’s role as protection for the President and foreign dignitaries, but as a branch of the Department of the Treasury, the Secret Service also investigates financial crimes. The types of offenses investigated by the Secret Service include investigating counterfeiting of U.S. currency, forgery or theft of U.S. Treasury checks, securities fraud, identity theft, credit card fraud, money laundering, and computer fraud. In addition to its investigative responsibilities, the Secret Service created a national Electronic Crimes Task Force—by mandate of the Patriot Act—with the express purpose of co-operation between federal and state agencies to help protect the country’s financial communications infrastructure. The FBI’s role in combating cybercrime is to stop individuals or groups that spread malicious software in the form of viruses and worms, identify and stop botnets, arrest those who traffic in or possess child pornography, stop individuals who prey on children in chat rooms or online, combat U.S. intellectual property theft, and hunt down organizations in the United States and internationally that engage in Internet fraud. With such a wide range of computer-related crimes that it must investigate, you can imagine that agents are busy. To help facilitate and triage computer crime complaints, the FBI and the National White Collar Crime Center set up the Internet Crime Complaint Center (IC3) to handle the high volume of calls for help. The IC3 provides a website where victims of Internet crimes can file a complaint. The IC3 website can be found at www.ic3.gov. Table 2-9 provides a list of computer-related crimes and the federal government agency that can assist with investigations. Table 2-9
Agencies to Call by Category of Crime
Category of Crime
Appropriate Agency
Computer Hacking
FBI, Secret Service, IC3
Password Trafficking
FBI, Secret Service, IC3
Child Pornography or Exploitation
FBI, U.S. Immigrations and Customs Enforcement (if brought in from outside the United States), IC3
Internet Fraud That Uses the Postal Services
United States Postal Inspection Services, IC3
Internet Fraud and SPAM
FBI, U.S. Secret Service, FTC, Securities and Exchange Commission (for investment-related span and fraud), IC3 continues
45
46
Network Security Auditing
Table 2-9
Agencies to Call by Category of Crime (continued)
Category of Crime
Appropriate Agency
Internet Harassment or Extortion
FBI
Copyrighted Materials Piracy FBI, U.S. Immigration and Customs Enforcement, IC3 Trademark Counterfeiting
FBI, Immigration and Customs Enforcement, IC3
Theft of Intellectual Property FBI or Trade Secrets If the crime occurs locally, the first place to start is with local state police. It can escalate the case if it turns out to be outside of the state’s jurisdiction. If the crime is obviously federal in nature or international, then contacting either the FBI or Secret Service is the most appropriate first step. Regardless of the type of crime or what agency the crime is reported to, a good incident-reporting process should be in place to provide the information needed by law enforcement to properly investigate the crime. At a minimum, the auditor should see evidence that the business being audited is prepared to provide the following: ■
Key contacts: A person assigned and trained to coordinate with law enforcement throughout the investigation. This should also be someone who knows the network and how things are configured.
■
Incident report: This is a document that provides all the pertinent facts regarding the case—the who, what, when, and where of the incident. In addition, if it is known how the information was taken, it should be included in this report.
■
Configuration and documentation: A topology map and technical details on the systems in question. Software versions, configuration files, system logs, and hardware types are all potentially relevant information.
Regulatory Compliance Laws Compliance laws and industry regulations have been a major driving force for adoptions of IT security controls. Through the use of these regulations, businesses are required to have the appropriate level of protection to protect their capability to accurately report financials and ensure the security of customer information. This section provides an overview of the Sarbanes-Oxley Act (SOX), Health Insurance Portability and Accountability Act (HIPAA), Grahmm-Leach-Bliley Act (GLBA), and Payment Card Industry (PCI), which represent the four most common compliance areas that auditors are asked to measure security controls in the network against.
SOX The Sarbanes-Oxley Act of 2002 is widely regarded as one of the most sweeping reforms of American corporate reporting since the 1934 creation of the Securities and Exchange Commission (SEC) by Franklin D. Roosevelt. SOX was enacted as a direct result of the
Chapter 2: Information Security and the Law
dramatic accounting scandals perpetrated by Enron, WorldCom, and others. Millions of investors lost significant sums of money, and the public’s trust in the accuracy of financial statements and reports was shattered. The primary purpose of SOX was to help restore that lost confidence in cooperate financial data, and to hold executives personally responsible for reporting accurately. Because practically all companies use computers to track and report financial and accounting information, SOX directly impacts IT departments. Ask any CIO of a publicly traded company to tell you about SOX, and you will probably be in for an animated conversation on how much money it has cost and the disruption it has caused. The act itself is roughly 66 pages, segmented into 11 Titles with multiple sections in each Title. These sections detail everything from the creating of the Public Company Accounting Oversight Board (PCAOB), auditor independence, corporate responsibility, and criminal penalties. The sections that are most relevant to IT auditors are the following:
■
Section 302 Corporate Responsibility for Financial Reports: This section requires that the CEO and CFO certify in quarterly or yearly filings with the SEC that they have reviewed the report being filed and it does not contain any untrue statements or is misleading in any way as to the financial state of the company. The signing officers are also required to establish internal controls that monitor the functionality and accuracy of the financial reporting system and have had those controls assessed 90 days prior to filing. Section 302 holds the CEO and CFO responsible for the accuracy of financial reports. The Department of Justice can also prosecute violations of 302 under mail and wire fraud.
■
Section 404 Management Assessment of Internal Controls: Section 404 dictates that management is responsible for creating and maintaining internal controls over financial accounting that address potential risks that could result in inaccurate reporting. The effectiveness of the controls implemented by management is to be tested and certified by external auditors in a yearly report. Basically, anything that could jeopardize the accuracy or completeness of financial numbers must be documented and disclosed.
■
Section 409 Real Time Issuer Disclosures: Real-time disclosure is defined in this section as “rapid and current.” After a risk to reporting is uncovered, any changes to reported information must be made available to the public as soon as possible. This section speaks clearly to IT and has been used to justify automated risk management packages and numerous monitoring tools.
■
Section 802 Criminal Penalties for Altering Documents: A strong records retention policy and procedures is critical to compliance with this section. It is required that all audit and work papers be saved for 5 years after the end of the fiscal year that the audit was preformed. This section also stipulates the retentions of any relevant audit documents, memos, correspondence, communications (including electronic records), and conclusions regarding the audit.
The brief summary of some of the highlights of SOX gives a glimpse at the complexity involved in complying with this law. The PCAOB has issued numerous auditing standards
47
48
Network Security Auditing
documents to help accountants and auditors tackle the complex set of requirements and nebulous mandates. As of July 25, 2007, Auditing Standard 5 was enacted to provide clearer guidance and hopefully reduce some of the ambiguity that exists in SOX that has cost companies millions of dollars in consulting and other fees associated with compliance. The goal is to help focus the internal control audit, mandated in section 404, on the most relevant portions of financial reporting process utilizing a risk-based, top-down approach. The changes also allow auditors to use previous years’ audits where there were no changes to process, instead of having to reassess the same things. Auditors are permitted to use the work of others (consultants or internal corporate auditors) to help streamline the auditing process where applicable. It’s important to note that in the 2007 guidance on SOX from the PCOAB that IT controls should only be part of a SOX assessment if they are directly part of or in support of addressing the risk of misstating earnings. This has helped to reduce the scope of SOX audits by focusing IT controls on auditing a much smaller subsection of IT governance. When SOX first came out, there was little guidance about what to audit, resulting in extensive IT audits that were not necessarily relevant. The following list highlights some of the areas that should be considered during a SOX audit: ■
IT general controls identified by Cobit or COSO that support the security and operation of financial reporting.
■
Any applications that are involved in the creation or processing of financial information.
■
Segregation of duties through access controls for providing checks and balances for employees that can make changes to data or processing.
■
Change management controls.
■
Security monitoring of applications and controls used to protect financial data.
■
Access controls for remote and local access to financial data.
■
Employee access privileges to financials should be granted and reviewed based on employees who need to know.
■
Financial e-mail messages, IM, and any other communications mechanism or systems used in processing financial records.
■
End user controls for spreadsheets on computers used to generate accounting data.
Table 2-10 summarizes key points of SOX.
HIPAA The Health Insurance Portability and Accountability Act of 1996 consists of two primary parts. Title I: Health Care Access, Portability, and Renewability is familiar to anyone who has changed or lost a job in which they took advantage of the ability to extend their
Chapter 2: Information Security and the Law
Table 2-10
Summary of Sarbanes-Oxley Act of 2002
SOX Offense
Description
Penalty
Executive officers required to cer- Up to $5,000,000 in fines §302 Corporate and/or 20 years in prison Responsibility for Financial tify the accuracy of the data in quarterly and yearly reports filed reports by the company §802 Alteration of Documents
Alteration or destruction of docu- Fines and/or maximum of ments pertaining to financial data 10 years in prison used before an investigation is performed
§903 Wire and Mail Fraud
Using computers or telecommunications devices to commit wire or mail fraud
Fines and/or maximum of 20 years in prison
§904 Employee Retirement Allows for prosecution under laws Fines up to $500,00 and 10 protecting fraud related to employ- years in prison Income Securities Act of ee retirement plans 1974 §906 Failure of Corporate Details penalties for knowingly and Officers to Certify Financial willfully certifying inaccurate or misleading company financial Reports reports § 1102 Tampering with a Record or Otherwise Impeding an Official Proceeding
Up to $1,000,000 in fines and/or 10 years in prison for knowing violations Up to $5,000,000 and/or 20 years for willful violation
Alteration, destruction, or mutila- Fines and/or up to 20 years in prison tion of documents pertaining to financial data to impede an official investigation or proceeding
health care coverage. HIPAA provided amendments to COBRA (health care continuation coverage), preventing discrimination against pre-existing illnesses, minimal coverage requirements, and a host of other things that your friends in Human Resources are involved with on a daily basis. Title II: Preventing Health Care Fraud and Abuse; Administration Simplification; Medical Liability Reform is the part most auditors and IT administrators working with health care organizations need to pay close attention to. Title II is intended to ensure the protection of all health care-related information, expedite access to health care data, reduce the chance for fraud, and ultimately allows health care providers the opportunity to streamline the processing required to receive payment for services rendered. The Department of Health and Human Services (HHS) Office for Civil Rights is responsible for providing guidance, investigation, and enforcing compliance with the Administrative Simplification portion of the law. To accomplish this goal, five standards were written to detail compliance requirements: Privacy Rule, Security Rule, Transactions and Code Sets Rule, Unique Identifiers Rule, and Enforcement Rule.
49
50
Network Security Auditing
HIPAA is a well-documented federal law that also has clear penalties for violation. Violation of the HIPAA Security Rule could cost organizations up to $250,000, and individuals face a potential prison time of 10 years. Two important terms used throughout the HIPAA law are Covered Entities and Business Associates. To understand HIPAA, you must understand who it applies to and to what degree it applies. These are: ■
■
Covered entities: Covered entities consist of those businesses responsible for enacting the HIPAA regulations. If your business handles any type of protected healthcare information via a healthcare plan or benefits administration, it is more than likely a covered entity. HIPAA’s three major categories of covered entities are: ■
Health plans: Health insurance plans, HMOs, or any other group or entity whose primary function is to pay for health care services.
■
Healthcare providers: Doctors, hospitals, or other providers of health care.
■
Healthcare clearinghouse: Any business or service that is involved in the processing, billing, or handling of health care information.
Business associates: Business associates are identified as individuals or businesses that are involved in any aspect of handling protected health care information and are not a member or employee of a covered entity. The business associate is required to sign a contract that stipulates what they can and can’t do with the information, and that they report to the covered entity any unauthorized use or disclosure. For example, a courier service that picks up and delivers lab samples from a physician group to a lab for testing is a business associate.
Privacy Rule The privacy rule was written and put into effect in 2003 to protect a person’s personally identifiable health care-related information in any “form or medium” from improper disclosure. It is a complex set of requirements for the handling of protected health care information (PHI) that defines who can handle health care information, what they can do with it, and penalties for improper disclosure or fraud. The HIPAA privacy rule requires that a covered entity make reasonable effort to disclose the “minimum necessary” when handling protected health care information. The term “minimum necessary” has been controversial as it is vague in describing the amount of effort that should be expended to secure health care information. Generally speaking, it is required to adopt the following practices: ■
Provide information to patients about their privacy rights.
■
Adopt a clear privacy policy for employees.
■
Provide training and continued education for privacy policy.
Chapter 2: Information Security and the Law
■
Identify a privacy officer to monitor and assess compliance and initially investigate possible infractions.
■
Define a security policy and set of procedures for handling protected health care information.
Security Rule The HIPAA Security Rule is technology neutral and does not specifically require any security technology or devices to comply. It is a set of minimum best practices around information security that is specifically intended to keep electronic protected health care information (EPHI) and nonelectronic protected health care information secure. It doesn’t address all risk possible, but it can be used as a component of an overall security governance program. The standards set forth by the security rule are divided into three categories: ■
Administrative: These standards provide guidance for delegation of responsibilities, risk analysis, and creating a sustainable security program.
■
Physical: These provide best practices for securing health care information systems from physical access, disaster, carelessness, and theft.
■
Technical: These standards provide guidance for technical controls, such as access control, authentication, and encryption.
Each standard is further identified as required or addressable. Required items must be implemented to achieve compliance with the law. Addressable items, however, are up to the covered entity as to whether or not they are applicable to their organization. Flexibility is afforded to implement other technologies or solutions, but the organization’s decision and reasoning must be documented thoroughly, based on security, risk, and financial analysis as to why they chose to deviate from the standard. The security rule is not a step-by-step guide to compliance. Although it provides guidance and flexibility, there are some key areas that need to be addressed: ■
A thorough risk analysis to determine how Electronic Protected Healthcare Information (EPHI) flows through a health care provider and the risks that data faces along the way
■
Role-based access control to limit only authorized individuals within an health care provider to EPHI
■
Monitoring tools and countermeasures to ensure the confidentiality, integrity, and availability of EPHI
■
Keeping EPHI safe from unauthorized people and software (hacker tools and viruses or worms)
■
Documented policies and procedures for access granting and revocation to EPHI
■
Periodic audits and assessments to validate policy and procedures
51
52
Network Security Auditing
For the complete text of the Security rule, go to http://www.cms.hhs.gov/SecurityStandard/Downloads/securityfinalrule.pdf.
Transactions and Code Sets Standard Rule The Transactions and Code Sets standard rule, which took effect in 2003, is important for overall HIPAA compliance and equally important as a requirement for health care organizations to get paid by insurance companies and Medicare or Medicaid. The bulk of this rule is focused on standardizing the codes used to identify procedures and services rendered based on the ANSI X12N standard. From an information security perspective, the electronic data interchange (EDI) aspects are worth noting. Most health care providers electronically file health care claims that use either the Internet or dialup as a transport mechanism. An auditor should be aware of the encryption strength and any potential protocol weakness in the systems submitting health care claims. These systems could be a tempting target for a would-be attacker.
Identifiers Rule Before HIPAA’s unique Identifiers rule, there was no standard way to identify a health care provider in the U.S. health care system. This caused significant delays in providers receiving payment for services. As part of the Healthcare Administration Simplification provisions in HIPAA, a national registry with unique National Provider Identifiers (NPI) was established in 2006.
Enforcement Rule A law is not effective without penalties and enforcement. The HIPAA Enforcement rule, made effective in 2006, details a series of penalties for noncompliance, and also provides a framework to investigate violations of the law. The department of Health and Human Services (HHS) is responsible for enforcement and investigation of HIPAA violations. The HHS follows a mostly passive approach to detection of violations as it relies on individuals and organizations to submit complaints. This has been one of the biggest challenges with HIPAA compliance, because it relies on voluntary adherence to the law. The HHS does have the authority to conduct compliance reviews. In 2009 the HITEC Act was passed, changing HIPAA penalties and enforcement significantly. What were previously considered light fines and consequences for noncompliance were changed to include stronger enforcement capabilities. The Enforcement rule allows for civil fines for the mishandling or unauthorized disclosure of PHI, if a complaint cannot be resolved informally. If a fine is assessed, the HHS can charge $100 per violation with a maximum fine of $1,500,000 in a calendar year for similar violations, depending on whether or not the organization was aware of the violation. This can be in addition to any criminal fines, which has resulted in a serious change to the effectiveness of HIPAA enforcement. In February 2009, for example, CVS Pharmacy was assessed, as of this writing, the largest fine in history for HIPAA violation totaling 2.25 million dollars. Table 2-11 shows the fines possible under the revised penalties for HIPAA violations.
Chapter 2: Information Security and the Law
HIPAA criminal enforcement is targeted at individuals who attempt to steal personal health care information. There have been numerous prosecutions of individuals under HIPAA.
Table 2-11
Fines for Violation of HIPAA Provisions
Violation Category of HIPAA Provisions
Fine for Each Violation
Maximum Fine for Violation of Identical Provisions in a Calendar Year
Did not know (and by exercising reasonable diligence would not have known) it violated HIPAA
$100–$50,000
$1,500,000
HIPAA violation due to reasonable cause and not willful neglect
$1,000–$50,000 $1,500,000
HIPAA violation due to willful neglect, but violation is corrected within the required time period
$10,000–$50,000 $1,500,000
HIPAA violation due to willful neglect and is not corrected in the required time period
$50,000
$1,500,000
Table 2-12 shows the criminal penalties for a HIPAA violation.
Table 2-12
HIPAA Criminal Penalties
Offense
Description
Penalty
Violation of HIPAA
Improper disclosure of individually identifiable health care information engaged in fraud
A person who knowingly obtains or discloses individually identifiable health information in violation of HIPAA faces a fine of up to $50,000 and up to 1-year imprisonment. Knowingly disclosing information under false pretenses raises the penalties to $100,000 and up to 5 years imprisonment. Willful disclosure with the intent to sell, transfer, or use individually identifiable health information for commercial advantage, personal gain, or malicious harm increases the penalties to $250,000 and up to 10 years imprisonment.
53
54
Network Security Auditing
GLBA The Grahmm-Leach-Bliley Act of 1999 (also known as the Financial Services Modernization Act) was enacted by Congress to address significant changes in the banking and financial services landscape that has occurred through the many mergers and acquisitions of the last 10 years. Although the bulk of GLBA was intended to allow banks to expand their service offerings through additional lines of business including insurance, stock brokerage, and investment services, the fact that the much larger and diversified banks would have unparalleled access to customers’ private information, it became necessary to include privacy laws to help limit disclosure. The privacy provisions require these organizations to securely store private information, create policies, communicate to the consumer how private information is to be used, and to give the consumer the right to opt out of their information being shared to third parties. The privacy protection laws are applied to financial institutions as defined by any organization “significantly involved in financial activities.” These laws are broken into two titles and codified under Title I: Disclosure of Non-Public Personal Information §§6801-6809 and Title II: Fraudulent Access to Financial Information §§6821-6827. This definition encompasses a wide range of businesses including banks, credit unions, investment firms, real estate appraisers, insurance companies, vehicle leasing services, and retail establishments that offer credit cards. Financial institutions must be careful about how they handle and share nonpublic personal information (NPPI). NPPI is classified as any information that a consumer provides to obtain a loan, credit card, or other financial service that is not public knowledge. There are three primary provisions of GLBA that organizations are required to comply with: ■
Financial Privacy Rule: The privacy rule requires that institutions under GLBA must provide privacy notices to consumers that detail how the institution uses and under what conditions it might disclose private information. These privacy notices must be provided when financial services are started, and then annually, as long as those services continue. The consumer must be afforded the opportunity to opt out of information that is shared with third parties.
■
Safeguards Rule: The safeguards rule mandates that a covered entity has a security policy and program in place that includes assigning an employee to coordinate and monitor the information security program. Additionally, GLBA requires that risk analysis be conducted to determine potential threats, design and deploy safeguards to secure data, and regularly test security controls (audit and assess).
■
Pretexting Protection: The act of pretexting is criminalized under federal law in GLBA. Pretexting is a form of social engineering and is used to manipulate someone into divulging personal information through misrepresentation or a pretext. This technique is used in bank fraud to get balance information, transfer funds, or other activities, and it requires research to obtain Social Security numbers or a mother’s maiden name to determine the identity of the caller. Financial institutions are instructed to secure customers’ private information, and as such, they need to create policies and procedures to prevent unauthorized disclosure through this method. Employee training and awareness programs should be leveraged, too. Pretexting is
Chapter 2: Information Security and the Law
permissible if it is used by authorized individuals to test the security safeguards of a financial institution. Auditors examining an organization for GLBA compliance should pay attention to a few specific areas. GLBA, like SOX and HIPAA, does not dictate any technology or technical safeguards in particular, such as firewalls or IPS, but it does provide specific guidance about how the safeguards rule on the results that need to be achieved. Protection of customer information is the primary requirement and that can be accomplished in a number of ways. Here is a recommended list of specific areas to look at: ■
Ensure the entity has a written information security policy and program.
■
Conduct periodic independent security assessments with risk analysis for potential threats at least yearly.
■
Ensure the organization identifies and ranks information assets (data and hardware) based on sensitivity and criticality.
■
Implement role-based access controls to permit only authorized access to customer information.
■
Ensure a change control mechanism is in place to monitor and approve configuration changes to key systems.
■
Ensure the organization has a security monitoring system to detect attacks or unauthorized access.
■
Ensure the organization has a documented incident-handling program and response in the event of a data breach.
■
Assess service providers (anyone providing a service for the financial institution) to ensure adherence to privacy safeguard requirements.
Table 2-13 provides a summary of the Criminal and Civil offenses for GLBA.
PCI DSS Practically everyone today has a credit card (or multiple cards) and it is tough to buy or sell anything in which a credit card is not involved. The ubiquity of the credit card makes it an incredibly enticing target for criminals all over the world. To help address uniformly securing credit card account information through industry best practices, Visa and MasterCard joined forces to develop the Payment Card Industry Data Security Standard (usually shortened to PCI DSS). The PCI standard has been endorsed by most of the major card issuers, including American Express, Discover, and JCB. Unlike the many laws discussed so far in this chapter, PCI is not a federal or state statute. Instead, PCI relies on a series of contractual obligations between the merchants and the credit card issuers so that anyone who processes, stores, or transmits credit card data must provide a minimum level of security to ensure the confidentiality and integrity of the cardholder data. If an organization wants to continue accepting and processing credit cards, it must adhere to the rules. PCI doesn’t provide penalties because the individual credit card issuers that follow PCI handle that aspect.
55
56
Network Security Auditing
Table 2-13
Summary of Grahmm-Leach-Bliley Act of 1999
GLBA Offense
Description
Penalty
Noncompliance with GLBA Privacy
Noncompliance with §§68016809
Financial institutions fined up to $100,000 per violation Officers and directors personally liable up $10,000 per violation Prison sentence up to 5 years.
§6821 Privacy Protection for Customer Information of Financial Institutions (Pretexting)
It shall be a violation of this subchapter for any person to obtain or attempt to obtain, or cause to be disclosed or attempt to cause to be disclosed to any person, customer information of a financial institution relating to another person— (1) by making a false, fictitious, or fraudulent statement or representation to an officer, employee, or agent of a financial institution; (2) by making a false, fictitious, or fraudulent statement or representation to a customer of a financial institution; or (3) by providing any document to an officer, employee, or agent of a financial institution, knowing that the document is forged, counterfeit, lost, or stolen, was fraudulently obtained, or contains a false, fictitious, or fraudulent statement or representation.
Fines for individuals up to $250,000 or maximum imprisonment of 5 years Fines for organizations up to $500,000 Aggravated penalty involving more than $100,000 in loss in 1 year, three times the amount of fines found in 18 U.S.C. § 3571 and a maximum of 10 years in prison
The PCI Security Council was created to maintain and update the data security standard. PCI DSS 1.2.1 is the most recent version of the standard and became effective August 2009. The PCI DSS provides detailed information about required security practices for protecting storage and transmission of cardholder information, and is divided into six main categories with 12 control objectives. PCI provides guidance about configuration of
Chapter 2: Information Security and the Law
security controls, wireless, and all other aspects of technology that are used in processing credit cards. Following are the PCI DSS 1.2.1 required controls: ■
■
■
■
■
■
Build and maintain a secure network: ■
Install and maintain a firewall configuration to protect data.
■
Do not use vendor-supplied defaults for system passwords and other security parameters.
Protect cardholder data: ■
Protect stored data.
■
Encrypt the transmission of cardholder data and sensitive information across public networks.
Maintain a vulnerability management program: ■
Use and regularly update antivirus software.
■
Develop and maintain secure systems and applications.
Implement strong access control measures: ■
Restrict access to data by a business on a need-to-know basis.
■
Assign a unique ID to each person with computer access.
■
Restrict physical access to cardholder data.
Regularly monitor and test networks: ■
Track and monitor all access to network resources and cardholder data.
■
Regularly test security systems and processes.
Maintain an information security policy: Maintain a policy that addresses information security.
The PCI standard is the agreed upon baseline for securing cardholder data, and based on the volume of credit card transactions processed per year, merchants are required to undergo specific validation requirements for compliance. In the case of Visa and MasterCard, both use similar methodologies for determining what a merchant or service provider should do to be in compliance. Visa Cardholder Information Security Program (CISP) and MasterCard’s Site Data Protection (SDA) have common criteria for identifying the risk level and validation requirements. Other credit card issuers don’t have the same commonality about requirements, so it is important that you read about the specifics for each issuer.
57
58
Network Security Auditing
Visa and MasterCard identify four levels of merchants and three levels of service providers: ■
■
Merchant levels: ■
Level 1 merchants have total yearly transactions greater than six million, and any merchant, regardless of size, that has had a cardholder data breach or is determined to be of significant risk. These merchants are required to conduct an annual onsite audit by a Qualified Security Assessor (QSA), and conduct a quarterly network security scan by an Approved Scanning Vendor (ASV).
■
Level 2 merchants have between one million and six million transactions a year. These merchants must submit an annual PCI DSS self-assessment questionnaire and conduct quarterly network scans with an approved ASV. MasterCard announced that it would require level 2 merchants to have an annual onsite security assessment by a QSA before December 31, 2010.
■
Level 3 merchants have 20,000 to one million e-commerce transactions per year. These merchants must submit an annual PCI DSS self-assessment questionnaire and conduct quarterly network scans with an approved ASV.
■
Level 4 merchants have less than 20,000 e-commerce transactions per year. This level also includes all other merchants that have less than one million transactions a year. These merchants must submit an annual PCI DSS self-assessment questionnaire and conduct quarterly network scans with an approved ASV.
Service provider levels: ■
Level 1 service providers consist of all VisaNet processors and all payment gateways. This class of provider processes, stores, or transmits payment transactions for merchants also known as a third-party processor. Validation requirements include annual onsite audits through a QSA and conduct a quarterly network security scan by an ASV.
■
Level 2 service providers are not a VisaNet processor or payment gateway and store, process, or transmit more than one million accounts/transactions a year. Validation requirements include annual onsite audit through a QSA and conduct a quarterly network security scan by an ASV.
■
Level 3 service providers are not a VisaNet processor or payment gateway and store, process, or transmit less than one million accounts/transactions a year. Validation requirements include an annual self-assessment and conduct a quarterly network security scan by an ASV.
Auditing Level 1 merchants or level 1-2 service providers for PCI compliance requires that you work for a QSA. QSAs are security-consulting firms certified by the PCI Security Council to conduct audits. The process for getting certified requires training, testing, and signing a business agreement adhering to the requirement and code of conduct with the PCI Security Council. There are a number of QSAs across the globe, with a complete list available on the PCI Security Standards Council website (www.pcisecuritystandards.org).
Chapter 2: Information Security and the Law
ASVs are companies that are authorized to conduct the remote penetration and vulnerability scanning required to be conducted quarterly by the various merchant and service provider levels. To become an ASV, a security solutions provider must pass a live remote scan test conducted by the PCI Security Standards Council. This test examines the capabilities of the security firm in conducting scans, finding vulnerabilities in networks and web applications, and the quality of the scan reports presented to the customer. After the PCI SSC has approved the vendor, it is then added to the list of ASVs and can be used by merchants and service providers. A complete list of ASVs can be found on the PCI Council’s website at www.pcisecuritystandards.org. The vast majority of merchants that must comply with PCI are required to file a PCI DSS self-assessment questionnaire. This document acts as a checklist to certify that the 12 requirements of the PCI standard are met, and questions are answered with a simple yes, no, or not applicable. If any portion of the checklist is answered with a no, the merchant or service provider is considered noncompliant and must fix lacking areas. The key for auditors reviewing PCI requirements is identifying what is in scope from a PCI perspective. Network segmentation is essential to reducing the number of devices and parts of the network that need to be assessed. PCI considers devices in scope if they have any potential to interact with the logical flow of cardholder information as it is transmitted and processed. Segmenting the network properly prevents unrelated devices such as printers and user workstations from being part of the compliance equation. All businesses can benefit from the documentation, excellent checklist for compliance, and general security controls PCI provides.
Summary This chapter provides information about several key federal and state laws that directly impact information security practices. Auditors must be aware of how laws influence the design and implementation of security systems and controls and the penalties for ignoring the laws. In summary: ■
Most of the hacking laws classify hacking as access without authorization. Make sure that you have permission for any security testing you might do while auditing networks and hosts.
■
Packet capture and monitoring networks for fraud and abuse in a corporate environment are perfectly legal. All organizations should have a well-defined monitoring policy that employees are aware of, and it is recommended to have them sign off of written policies.
■
Make sure that you attain professional legal advice when building corporate information security policies. Many of the laws are tricky and constantly changing.
■
Developing a strong information security strategy that leverages best practices can help to comply with multiple regulations.
59
60
Network Security Auditing
References in This Chapter Harris, Shon, et. All. Gray Hat Hacking: The Ethical Hackers Handbook. McGraw-Hill Osborne, 2005. Wright, Benjamin. Business Law & Computer Security. SANS Institute, 2004.
Federal Hacking Laws United States Department of Justice: Computer Crime and Intellectual Property Section, http://www.cybercrime.gov Prosecuting Computer Crimes, http://www.cybercrime.gov/ccmanual/index.html Prosecuting Intellectual Crimes Manual, http://www.cybercrime.gov/ipmanual/index.html Robinson, Steven, U.S. Information Security Law Part1-4,www.SecurityFocus.com Alabama infraguard Computer crime summary, http://www.infragardmo.net/Computer_Crimes_Statute_Summary.htm Federal Bureau of Investigations: Cybercrime Division, http://www.fbi.gov/cyberinvest/cyberhome.htm United States Secret Service: Electronic Crimes Task Force, http://www.secretservice.gov/ectf.shtml
State Laws National Conference of State Legislatures, http://www.ncsl.org/IssuesResearch/ TelecommunicationsInformationTechnolgy/ComputerHackingandUnauthorizedAccessLaws/ tabid/13494/Default.aspx SOX, http://en.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act PCAOB, http://pcaobus.org/Pages/default.aspx HIPAA, http://www.hhs.gov/ocr/privacy/ GLBA, http://www.ftc.gov/privacy/privacyinitiatives/glbact.html and http://en.wikipedia.org/wiki/Gramm%E2%80%93Leach%E2%80%93Bliley_Act PCI standards, https://www.pcisecuritystandards.org/index.shtml
Chapter 3
Information Security Governance, Frameworks, and Standards To audit a process, procedure, or technology, you must first measure the current state against the desired state; this enables you to identify the gaps. The terms “best practice” and “standards” are used to describe how a company should configure or manage its security controls, but if you put two security professionals in a room and asked them to describe the best way to accomplish a particular company’s goals, you would likely get a slew of different answers. With all of these best practices floating around, it becomes difficult to pick the “better” practice and it comes down to determining what fits the organization as a whole and that is where understanding information security governance becomes so important. Governance drives the organization to institute best practices and measures its performance. A best practice doesn’t become a standard until the organization adopts it and decides to comply with it. Auditors need to be aware of various best practices and industry standards available today to better tailor audits to the companies for which they are conducting them. This chapter introduces key concepts of information security governance and a few of the most common frameworks and standards that can be used to build a checklist to audit networks in a manageable and measurable fashion.
Understanding Information Security Governance Information security governance is a part of an overall IT governance strategy that is focused on reducing risk and providing value back to the organization in the form of protecting assets and aligning to business needs. Governance is about assigning responsibility for the use and protection of corporate assets to the managers and employees entrusted with their care in addition to measuring the results of their actions. Data has become one of the most valuable assets a company possesses, and its proper protection is no longer best effort but required by law and shareholders. Scanning through laws like HIPAA, GLBA, and SOX, you will find that each one identifies either the board of directors or executive management as being ultimately responsible for securing corporate data. To adhere to the law and to provide due care in managing the business data, organizations must build a sustainable security program that addresses these requirements.
62
Network Security Auditing
A security governance strategy provides the blueprint to direct and control the security program with clearly defined goals and objectives. Figure 3-1 shows how information security governance provides the glue to coordinate the efforts of people, processes, and technologies to better secure the key assets of a company.
Information Security Governance
Process
People
Figure 3-1
Technology
Information Security Governance Infrastructure
When a business builds a security governance strategy, it can rely on frameworks, standards, and guidelines to address specific controls and processes that are part of the security program. Looking at the various standards documents, it is clear that there is overlap between them. No one standard addresses all of the needs of a security program, though some, such as COBIT, get close; most successful programs leverage some pieces from each. By grouping the standards into the categories of people, process, and technology, it is easier to see how they can be used together to shore up the weaknesses and leverage the strengths of each. Figure 3-2 shows how some of the key standards and frameworks overlap while also highlighting where they are the strongest.
Information Security Governance
Process
People
Figure 3-2
Technology
Overlapping Standards and Frameworks Provide Strength
Although the governance strategy is different depending on a company’s tolerance for risk, size, and regulatory requirements, there are a number of common elements that all
Chapter 3: Information Security Governance, Frameworks, and Standards 63
companies should address. Some of the objectives and deliverables of an information security governance program are as follows: ■
Alignment of information security with the business’s strategy and objectives
■
Effective management and utilization of resources (people and technologies) with a clearly defined organizational structure
■
Risk management to reduce the potential impact of events on information systems assets
■
Security policies to address business requirements and regulatory compliance
■
Security standards for each policy so that procedures and guidelines are defined
■
Performance management through measurement, monitoring, and reporting to track attainment of organizational security objectives
■
Assessment of security processes and procedures to measure effectiveness and compliance
■
A review and update process for security policies, standards, and procedures
■
A process for the evaluation of new threats and risks to the organization
■
Optimized usage of security investments
■
Integration of security into all aspects of the business
■
Security awareness training
Analyzing a security governance program requires that the auditor have detailed information about how the organization conducts itself. No two companies are exactly alike in this respect; however, there are five main areas that auditors should focus attention on to determine the effectiveness of the security program. The first area starts at the senior management level. Senior management sets the tone and culture for the organization, the priorities, and strategy. If the organization has poor support from management or management doesn’t seem to take security seriously enough, then all other areas of the security program will suffer. Many executives still think of security as being an IT or technology problem and would rather spend money on controls than tackle the larger job of changing the organization’s approach to security. If the security group finds it difficult to get the appropriate tools or make changes when risk is identified, there is a strong possibility that the biggest threat to the organization might ultimately be the organization itself. Auditors should look for these types of issues by talking to employees and administrators to identify these issues. More than likely, auditors will find that the security governance strategy is weak and can make recommendations about how to better articulate and report on risks to the organization. The second area that should be examined is the specifics of the security program. This starts by examining the goals and objectives of the security program to determine if the goals are attainable, measurable, and realistic given the organization’s risk profile and business model. Looking at the policies in place and controls identified to enforce the policies
64
Network Security Auditing
will provide a view of the security architecture. If policies are in place but they are either not enforced or adhered to inconsistently, it is difficult to manage these policies. After the security architecture is identified, the auditor can start planning for how to test the effectiveness of policy and architecture and relevancy to the goals of the program. The third area is how the organization measures its successes and failures in execution of the security program. Measurement is critical to any process operating successfully, and analyzing how a company measures itself can be telling for an auditor. Identifying performance goals, program maturity levels, and success criteria can show how the business sets priorities for security. Audit and assessment is the execution of security management and a critical component of management of the program. The fourth area is the risk-management program. Risk management drives security architecture development and deployment. Knowing how the business selects and identifies controls is an important part of managing risk. Buying products before risk is quantified is like “putting the cart before the horse.” Doing this can lead to placing technology into the network without necessarily adding real value. The final area concerns how the business addresses continuous improvement of its security program. One of the quickest ways to see whether a company is improving its security posture is to look at past audits to determine whether the same deficiencies are being identified audit after audit. This indicates quite clearly that the company didn’t have an effective improvement process for security. Auditors should also determine whether the organization has a process for updating policies and procedures as new technologies and risks are identified. Stale policies and outdated procedures do not lend themselves to being effective tools, requiring individuals to modify or augment the procedures to accomplish their jobs. This type of adaptation means inconsistent deployments and increases the risk of opening up vulnerabilities. Security governance is successful only if it is sponsored and managed from the top. Executives must make it a component of measuring business success.
People: Roles and Responsibilities In the not so distant past, the responsibilities of a company’s security administrator primarily consisted of adding, removing, and resetting user accounts and passwords. As the role of IT in business has evolved, so have the requirements and responsibilities of the information security functions of most corporations. Companies have hired CIOs and Chief Information Security Officers (CISO), and numerous organizational structures have been implemented to get a handle on the complexities associated with managing and protecting data. Regardless of how the teams are divided, the goal is to ensure a clear reporting structure that requires accountability at every level.
Chapter 3: Information Security Governance, Frameworks, and Standards 65
Information Security Governance Organizational Structure Figure 3-3 shows a sample information security governance organizational structure.
Board of Directors
CEO Security Steering Comittee CIO/CISO
Director of Security
Intelectual Property
Figure 3-3
Security Architect
Security Analyst
Internal Auditor
Information Security Governance Organizational Structure
Information security governance begins at the top with the Board of Directors and CEO enforcing accountability for adherence to standards and commissioning the development of security architectures that address the security requirements of the business as a whole. The auditing function might be its own group (or outsourced to a third party) and might report to the CEO or directly to the Board of Directors to maintain its independence.
Board of Directors The Board of Directors is responsible for protecting the interests of the shareholders of the corporation. This duty of care (fiduciary responsibility) requires that it understand the risk to the business and its data. The Board of Directors is responsible for approving the appropriate resources necessary to safeguard data. It also needs to be kept aware of how the security program is performing.
Security Steering Committee The Security Steering Committee has an important role in security governance; this group is responsible for setting the tactical and strategic direction for the organization as a whole. The group generally consists of the CEO, CFO, CIO/CISO, and the internal auditing function (or oversight if it is outsourced to a third party). Other business functions might also be present, such as Human Resources and business operational leaders, depending on the size and organizational complexity of the business. This team reviews
66
Network Security Auditing
audit results, risk assessment, and current program performance data. The committee also provides approval for any major policy or security strategy changes.
CEO or Executive Management Senior management must answer to the Board of Directors and shareholders of a company. Furthermore, if the company is publicly traded, the CEO and CFO must personally attest to the accuracy and integrity of the financial reports the company issues. Executive management sets the tone and direction for the rest of the company and must be aware of the risks the company faces for the confidentiality, integrity, and availability of sensitive data.
CIO/CISO The CIO/CISO is responsible for aligning the information security program strategy and vision to business requirements. The CIO/CISO ensures that the correct resources are in place to adhere to the policies and procedures set forth by the steering committee. This role generally reports to the CEO and Board of Directors and reports how the organization is performing relative to the company’s goals and similar organizations in the same industry.
Security Director The security director’s role is to coordinate the efforts for securing corporate assets. The responsibilities include reporting on the progress of initiatives to executive management and building the teams and resources to address the various tasks necessary for information security. This role also acts as a liaison to other aspects of the business to articulate security requirements throughout the company. The security director manages the teams in developing corporate data security policies, standards, procedures, and guidelines.
Security Analyst A security analyst builds the policies, analyzes risk, and identifies new threats to the business. Business continuity and disaster recovery planning are important functions performed by the analyst to prepare the company for the unexpected. The analyst is also responsible for creating reports about the performance of the organization’s security systems.
Security Architect A security architect defines the procedures, guidelines, and standards used by the company. Architects help to select the controls used to protect the company’s data and they make sure that the controls are sufficient for addressing the risk and complying with policy. This role is also responsible for testing security products and making recommendations about what will best serve the needs of the company.
Chapter 3: Information Security Governance, Frameworks, and Standards 67
Security Engineer A security engineer implements the controls selected by the security architect. Security engineers are responsible for the maintenance of firewalls, IPS, and other tools. This includes upgrades, testing, patching, and overall maintenance of the security systems. This role might also be responsible for testing the functionality of equipment to make sure that it operates as expected.
Systems Administrator A systems administrator is responsible for monitoring and maintaining the servers, printers, and workstations a company uses. In addition, administrators add and/or remove user accounts as necessary, control access to shared resources, and maintain company-wide antivirus software.
Database Administrator The Database Administrator (DBA) has an important job in most companies. The DBA is responsible for designing and maintaining corporate databases and also securing access to the data to ensure its integrity. The ramifications of lax security in this role can be severe, especially considering the reporting requirements mandated by SOX.
IS Auditor An auditor’s role in security governance is to assess the effectiveness in meeting the requirements set forth by policy and management direction. The auditor is tasked to identify risk and report on how the organization performs to upper management. The auditor provides an impartial review of projects and technologies to identify weaknesses that could result in loss to the company.
End User End users have a critical role in security governance that is often overlooked. They must be aware of the impact their actions can have on the security of the company and be able to safeguard confidential information. They are responsible for complying with policies and procedures and following safe computing practices, such as not opening attachments without antimalware software running or loading unauthorized software. A solid user security awareness program can help promote safe computing habits.
Spotting Weaknesses in the People Aspect of Security There are many different roles involved in securing the assets and a data of a company. An auditor should be on the lookout for areas that might represent opportunities to improve how a company instills security as part of corporate culture. Confusion and lack
68
Network Security Auditing
of direction are often signs of weakness in management’s commitment to protecting assets. Some things to be on the lookout for are: ■
Lack of management commitment to security
■
Key assets not identified and inventoried
■
Poor adherence to processes and procedures
■
No follow-up on issues identified
■
Apathy toward security
■
Lack of segregation of duties in key roles
■
Inconsistent application of policy
■
Poor communication between roles
■
Unclear job descriptions or roles
■
Poor documentation
Process: Security Governance Frameworks Security governance frameworks represent solutions to the question of how to manage security effectively. The manner in which a company builds a governance structure is a reflection of the organization of the company and the laws and business environment in which it finds itself. Auditing the security governance practices of a company requires understanding how the organization manages the processes and procedures that make up its security program and compare those aspects to recognized governance frameworks. Luckily, there are many sources that an auditor can use to identify best practices in building a manageable, measurable, and effective security governance program. The frameworks mentioned in this text are not a complete list, and significant research is constantly being conducted in this area. What follow are three of the most frequently found frameworks, and should get you started in understanding how they can be applied to the organizations you audit.
COSO The Foreign Corrupt Practices Act of 1977 (FCPA) is a law that requires any publicly traded company to accurately document any transactions or monetary exchanges it is involved in (to prevent off-the-books money transfers). Additionally, the law requires that a publicly traded company also have a system of internal accounting controls to monitor fraud and abuse and test them through compliance auditing. This law had little guidance from the Securities and Exchange Commission (SEC), and in response to this, a consortium of private organizations created the Treadway Commission to figure out what companies needed to do to comply with this law. The Committee of Sponsoring Organizations of the Treadway Commission (COSO) was formed in 1985 to improve the accuracy of financial reports and to standardize on internal control methods to reduce
Chapter 3: Information Security Governance, Frameworks, and Standards 69
fraudulent reporting. COSO studied the problem and issued guidance about how to create an internal controls framework that complies with the FCPA. The resulting document, called “Internal Controls: Integrated Framework,” was published in 1994 and provided common language, definitions, and assessment methodologies for a company’s internal accounting controls. This COSO report is considered the standard by which accounting auditors assess companies to ensure compliance with the FCPA and SOX section 404. The COSO report lists a few main concepts that guided the development of the COSO framework and define what internal controls can and cannot do for an organization. These concepts show the relationship between people and processes in respect to the effectiveness of controls, and they define the principles with which to implement them: ■
Internal control is a process and not a one-time activity.
■
Internal control is affected by people; it must be adopted through the organization and is not simply a policy document that gets filed away.
■
An internal control can provide only reasonable assurance, not absolute assurance, to the management and board of a business. A control cannot ensure success.
■
Internal controls are designed for the achievement of business objectives.
The COSO internal controls framework consists of five main control components as seen in Figure 3-4. These controls are the foundation of the COSO framework and provide a means for auditors to assess a company’s control efficiency, effectiveness, reliability of financial reporting, and compliance with the law.
Monitor Information and Communication Control Activities
Risk Assessment
Control Environment
Figure 3-4
COSO Internal Controls Framework
Control Environment The control environment defines how an organization builds its internal governance program and affects the company as a whole. The CEO, Board of Directors, and executive management are most involved at this level, creating the ethics environment and organiza-
70
Network Security Auditing
tional structure and defining the roles and responsibilities. The control environment consists of the people, culture, and ethics of the business.
Risk Assessment Solid risk assessment methodologies are important to any successful governance program. COSO identifies this area as critical to all control development activities and for identifying business objectives. You can’t protect what you don’t know about, so a thorough risk assessment provides the data to help a company design controls to protect its assets and achieve its strategic goals.
Control Activities This section covers the controls that COSO recommends to help mitigate risk. The main categories for controls in COSO are operational, financial reporting, and compliance. The controls identified are broad in nature and cover some IT-related issues, but COSO doesn’t address this area as well for IT as it does the accounting side. It does highlight the various activities that should be controlled, but leaves it up to management to figure out how to do it.
Information and Communication Having an organization in which information and communication are free to flow between all aspects of the business is addressed in this component of COSO. Information, according to COSO, is the data used to run the business, whereas communication is defined as the method used to disseminate information to the appropriate individuals. People cannot do their jobs efficiently and effectively if they are not provided with the necessary information. Without the appropriate lines of communication and timely action, problems can turn into catastrophes. Communication is the mechanism that drives the other four components of the COSO framework.
Monitoring Auditing and measurement are essential in determining how controls perform. Monitoring can be the alarm system that identifies a problem and provides valuable data for fixing issues for the future. Monitoring can consist of periodic reports, audits, or testing mechanisms that provide the status of individual controls. COSO is one of the more widely adopted internal control frameworks for large companies due in no small part to the mandates set forth through SOX 404. In response to criticism that the framework was impractical for smaller organizations, the committee published “Internal Control over Financial Reporting for Small Public Companies” in 2006. The COSO framework represents the grandfather of internal controls and though it was designed primarily for accounting controls, it still provides value for companies building out a security governance strategy. From an IT perspective, the five main components are
Chapter 3: Information Security Governance, Frameworks, and Standards 71
entirely relevant to securing information, but the actual controls themselves don’t go to the same level of depth as other frameworks such as Control Objects for Information and related Technologies (COBIT).
COBIT The COBIT framework was created by the Information Systems Audit and Control Association (ISACA) and IT Governance Institute (ITGI) as a response to the needs of the IT community for a less generalized and more actionable set of controls for securing information systems. The ITGI is a nonprofit organization that leads the development of COBIT through committees consisting of experts from universities, governments, and auditors from across the globe. The COBIT framework is a series of manuals and implementation guidelines for creating a full IT governance, auditing, and service delivery program for any organization. COBIT is not a replacement but an augmentation to COSO, and maps directly to COSO from an IT perspective. Although COSO covers the whole enterprise from an accounting perspective, it does so by providing high-level objectives that require the business to figure out how to accomplish them. COBIT on the other hand, works with COSO by fully detailing the necessary controls required and how to measure and audit them. The built-in auditable nature of COBIT is why it has become one of the leading IT governance frameworks as it gets as close as can be expected to a turnkey governance program. COBIT does not dig down into the actual tasks and procedures however, which necessitates using other sources to develop standards and procedures for implementing the controls. In other words, COBIT won’t tell you the best way to configure AES encryption for your wireless infrastructure, but it will provide you with a mechanism for identifying where and why you need to apply it based on risk. The role of COBIT in IT governance is to provide a model that takes the guesswork out of how to bridge the gap between business goals and IT goals. COBIT considers business the customer of IT services. Business requirements (needs) ultimately drive the investment in IT resources, which in turn need processes that can deliver enterprise information back to the business. The cyclical nature of business needing information and IT delivering information services are the foundation of COBIT. Information is what IT provides to the business and COBIT defines the following seven control areas as business requirements for information: ■
Effectiveness: Information should be delivered in a timely, correct, consistent, and usable manner.
■
Efficiency: Information is delivered in the most cost effective way.
■
Confidentiality: Data is protected from unauthorized disclosure.
■
Integrity: The business is protected from unauthorized manipulation or destruction of data.
■
Availability: Data should be accessible when the business needs it.
■
Compliance: There is adherence to laws, regulations, and contractual agreements.
72
Network Security Auditing
■
Reliability of information: Data correctly represents the state of the business and transactions.
IT resources in COBIT are the components of information delivery and represent the technology, people, and procedures used to meet business goals. Resources are divided into four areas: ■
Applications: Information processing systems and procedures
■
Information: The data as used by the business
■
Infrastructure: Technology and systems used for data delivery and processing
■
People: The human talent needed to keep everything operating
IT processes (or activities) are the planned utilization of resources and divided into four interrelated domains. Each process has its own controls that govern how the process is to be accomplished and measured. There are 34 high-level processes and hundreds of individual controls. The domains and processes are: ■
■
Plan and Organize (PO): Defines strategy and guides the creation of a service and solutions delivery organization. The high-level process for this domain is as follows: ■
PO1 Define a strategic IT plan.
■
PO2 Define the information architecture.
■
PO3 Determine technological direction.
■
PO4 Define the IT processes, organization, and relationships.
■
PO5 Manage the IT investment.
■
PO6 Communicate management aims and direction.
■
PO7 Manage IT Human Resources.
■
PO8 Manage quality.
■
PO9 Assess and manage IT risks.
■
PO10 Manage projects.
Acquire and Implement (AI): Builds IT solutions and creates services. The high-level process for this domain is as follows: ■
AI1 Identify automated solutions.
■
AI2 Acquire and maintain application software.
■
AI3 Acquire and maintain technology infrastructure.
■
AI4 Enable operation and use.
■
AI5 Procure IT resources.
Chapter 3: Information Security Governance, Frameworks, and Standards 73
■
■
■
AI6 Manage changes.
■
AI7 Install and accredit solutions and changes.
Deliver and Support (DS): User facing delivery of services and solutions. The highlevel process for this domain is as follows: ■
DS1 Define and manage service levels.
■
DS2 Manage third-party services.
■
DS3 Manage performance and capacity.
■
DS4 Ensure continuous service.
■
DS5 Ensure systems security.
■
DS6 Identify and allocate costs.
■
DS7 Educate and train users.
■
DS8 Manage service desk and incidents.
■
DS9 Manage the configuration.
■
DS10 Manage problems.
■
DS11 Manage data.
■
DS12 Manage the physical environment.
■
DS13 Manage operations.
Monitor and Evaluate (ME): Monitors IT processes to ensure synergy between business requirements. The high-level process for this domain is as follows: ■
ME1 Monitor and evaluate IT performance.
■
ME2 Monitor and evaluate internal control.
■
ME3 Ensure compliance with external requirements.
■
ME4 Provide IT governance.
Each of the processes in COBIT is written for managers, users, and auditors by addressing each group’s needs. Each process control objective is built using a template that includes: ■
A general statement that provides answers to why management needs the control and were it fits
■
The key business requirements that the control addresses
■
How the controls are achieved
■
Control goals and metrics
■
Who is responsible for each individual control activity
74
Network Security Auditing
■
How the controls can be measured
■
Clear descriptions of measuring how mature the organization is in accomplishing the control using a detailed 0–5 scale Maturity Model
Measurement of each process and controls is accomplished through a Maturity Model. The COBIT Maturity Model is based on the Capabilities Maturity Model pioneered by Carnegie Mellon’s Software Engineering Institute (SEI). The Capabilities Maturity Model was designed as a tool for ensuring quality software development. COBIT has modified the model to deliver a measurement and tracking tool that identifies the current state of adoption (maturity level) for each process so as to compare an organization execution with industry averages and business targets. This helps management identify where the company’s performance is in relations to its peers and provides a path to improve with specific and prescriptive steps used to get there. The COBIT Maturity Model scale provides the following measurements, as illustrated in Table 3-1. Table 3-1
COBIT Maturity Scale
0 Nonexistent
Not performed
1 Initial/Ad hoc
Process is chaotic, not standardized, and done case by case.
2 Repeatable but intuitive
Relies on individual knowledge,